From fyang at openjdk.java.net  Wed Jun  1 01:07:32 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 1 Jun 2022 01:07:32 GMT
Subject: RFR: 8287552: riscv: Fix comment typo in li64
In-Reply-To: <t4vPXE5izZLNNDXAZplr6AWDPxI8qwJqw1rR1cPWj74=.62c0816f-f052-487f-9a57-d70e6200eda5@github.com>
References: <t4vPXE5izZLNNDXAZplr6AWDPxI8qwJqw1rR1cPWj74=.62c0816f-f052-487f-9a57-d70e6200eda5@github.com>
Message-ID: <YXvTxYHmIkh84GZW5VCxABkHJtjJ7nbAFwqcQz31fx8=.10d817a0-f3d3-4738-8ca5-47ba392344cf@github.com>

On Tue, 31 May 2022 07:59:21 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> In riscv, 'imm[31:28]? should be 'imm[31:20]' for '0x7ff' in the following two places:
> 
> src/hotspot/cpu/riscv/assembler_riscv.cpp:
> 
> 
> void Assembler::li64(Register Rd, int64_t imm) {
> // Load upper 32 bits. upper = imm[63:32], but if imm[31] == 1 or
> // (imm[31:28] == 0x7ff && imm[19] == 1), upper = imm[63:32] + 1.
> int64_t lower = imm & 0xffffffff;
> 
> 
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp:
> 
> 
>   // Load upper 32 bits. Upper = target[63:32], but if target[31] = 1 or (target[31:28] == 0x7ff && target[19] == 1),
>   // upper = target[63:32] + 1.
> 
> 
> This patch also unifies the immediate type in `movptr_with_offset` to `int64_t`.
> 
> Hotspot tier1 test on QEMU passed without new failures.

Looks fine.

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

Marked as reviewed by fyang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8950

From dlong at openjdk.java.net  Wed Jun  1 02:04:31 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 1 Jun 2022 02:04:31 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
Message-ID: <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>

On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. 
> 
> I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed.

Is there any advantage to having the first instruction be "nop" instead of a branch that skips over the movks? 

b done
movk zr, lo
movk zr, hi
done:

 I was going to suggest:

 b done
 (raw data)
 done:

but then it might be hard for NativePostCallNop::check() to prevent false positives.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From alanb at openjdk.java.net  Wed Jun  1 06:04:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Jun 2022 06:04:14 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Fixed another typo in comment
 - Merge
 - Fix typos in comments
 - Allowing linking without intrinsic stub, contributed-by: rehn
 - Continuation clinit should fail if no continuations support
 - Fix merge issue with test
 - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
 - Update
 - Expend test coverage
 - Merge
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

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

Changes: https://git.openjdk.java.net/jdk/pull/8939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=02
  Stats: 747 lines in 72 files changed: 574 ins; 53 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939

PR: https://git.openjdk.java.net/jdk/pull/8939

From shade at openjdk.java.net  Wed Jun  1 06:05:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 06:05:39 GMT
Subject: Integrated: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <jIFGi8wjZIj-EwfNs7gLylJoHNocD_UjZEKWdMaZYPg=.cdc07e0e-b911-484f-a307-e27c97d8272f@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] GHA run

This pull request has now been integrated.

Changeset: 71599763
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71599763359055c81afbe5e04d6034b7bb3f3606
Stats:     143 lines in 3 files changed: 0 ins; 142 del; 1 mod

8287520: Shrink x86_32 problemlists after JDK-8287437

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8946

From rbackman at openjdk.java.net  Wed Jun  1 06:08:32 2022
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Wed, 1 Jun 2022 06:08:32 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
Message-ID: <LbTUEyE7aQY3ArdGVh2aqzR2zuxbbQHLpyoDplUKI5Q=.5f7950fb-062e-43de-a90d-5906c34b0aeb@github.com>

On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. 
> 
> I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed.

Marked as reviewed by rbackman (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From rbackman at openjdk.java.net  Wed Jun  1 06:08:34 2022
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Wed, 1 Jun 2022 06:08:34 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
Message-ID: <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>

On Wed, 1 Jun 2022 02:01:02 GMT, Dean Long <dlong at openjdk.org> wrote:

> Is there any advantage to having the first instruction be "nop" instead of a branch that skips over the movks?
> 
> ```
> b done
> movk zr, lo
> movk zr, hi
> done:
> ```
> 
> I was going to suggest:
> 
> ```
>  b done
>  (raw data)
>  done:
> ```
> 
> but then it might be hard for NativePostCallNop::check() to prevent false positives.

The NOP is required for deoptimization.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From dholmes at openjdk.java.net  Wed Jun  1 06:23:32 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 06:23:32 GMT
Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to
 execute native method as non-native [v2]
In-Reply-To: <MPaklLwrgzfdP2xh6TXAZ1RYhjFprGoLEUqajj0fCUU=.69ac26b9-ed4b-48f6-9857-827b9aa3fc30@github.com>
References: <yMwnynv2x_Xw-2JKkQG8wG_b2PehcC5GStj3YAZF1NA=.ddf3d025-6d00-4461-9acb-c09a7eec5cc6@github.com>
 <MPaklLwrgzfdP2xh6TXAZ1RYhjFprGoLEUqajj0fCUU=.69ac26b9-ed4b-48f6-9857-827b9aa3fc30@github.com>
Message-ID: <YshwzJ7ei_8ij1znVELgPULfJLQIQUxDGPAPDe9W9PA=.90b4bdf7-57fd-47fe-91db-782f950a9db6@github.com>

On Tue, 31 May 2022 15:45:30 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial.
>> 
>> Passes Loom tiers 1-5.
>
> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change memory barriers

Update looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8926

From dholmes at openjdk.java.net  Wed Jun  1 06:29:29 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Jun 2022 06:29:29 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
Message-ID: <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>

On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed another typo in comment
>  - Merge
>  - Fix typos in comments
>  - Allowing linking without intrinsic stub, contributed-by: rehn
>  - Continuation clinit should fail if no continuations support
>  - Fix merge issue with test
>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>  - Update
>  - Expend test coverage
>  - Merge
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

src/java.base/share/classes/java/lang/Thread.java line 742:

> 740:      * @param name thread name, can be null
> 741:      * @param characteristics thread characteristics
> 742:      * @param bound true when bound to an OS thread

Nit: s/OS/VM/ ?

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From dlong at openjdk.java.net  Wed Jun  1 07:36:35 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 1 Jun 2022 07:36:35 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
Message-ID: <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>

On Wed, 1 Jun 2022 06:05:37 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> The NOP is required for deoptimization.

I could be wrong, but I thought aarch64 allowed undefined instructions to be patched on top of branch instructions too.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From aph at openjdk.java.net  Wed Jun  1 07:50:33 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 1 Jun 2022 07:50:33 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
Message-ID: <5rxAPH8e85_fuIg4YoxiolQY4LwLrgJoPG1QRDzOTz4=.553d9d9d-e3f5-4133-904b-499d07216a0c@github.com>

On Wed, 1 Jun 2022 06:05:37 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> Is there any advantage to having the first instruction be "nop" instead of a branch that skips over the movks?

That's an interesting question. I've been looking at the performance data for some high-end AArch64 implementations, and I see that they all can execute multiple movks per cycle. Apple M1 can do 6/cycle, Arm Neoverse N2 can do 4/cycle. One both of these cores, the nops cost nothing except code cache space: on M1, nops don't even issue: they are consumed by the front end. On Neoverse N2, a nop is fused with any following instruction, so the total cost is at most 2 movks.

> I was going to suggest:
> 
> ```
>  b done
>  (raw data)
>  done:
> ```
> 
> but then it might be hard for NativePostCallNop::check() to prevent false positives.

Impossible, I would have thought. The raw data might match any instruction: you need some redundancy somewhere.
There is a way to compress the raw data down to 20 bits, by using 6 bits as an index and 14 bits as an offset. But that's a micro-optimization for another day, I think.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From aph at openjdk.java.net  Wed Jun  1 07:52:32 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 1 Jun 2022 07:52:32 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
 <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
Message-ID: <vFTfljmeNlIbG7nA6P4jWHoSN-Ua_AlKr8mezi7Pkfk=.b1711471-b777-4db3-9eb6-c81e3957aea6@github.com>

On Wed, 1 Jun 2022 07:32:35 GMT, Dean Long <dlong at openjdk.org> wrote:

> > The NOP is required for deoptimization.
> 
> I could be wrong, but I thought aarch64 allowed undefined instructions to be patched on top of branch instructions too.

That's true.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From fjiang at openjdk.java.net  Wed Jun  1 09:04:37 2022
From: fjiang at openjdk.java.net (Feilong Jiang)
Date: Wed, 1 Jun 2022 09:04:37 GMT
Subject: RFR: 8287552: riscv: Fix comment typo in li64
In-Reply-To: <YXvTxYHmIkh84GZW5VCxABkHJtjJ7nbAFwqcQz31fx8=.10d817a0-f3d3-4738-8ca5-47ba392344cf@github.com>
References: <t4vPXE5izZLNNDXAZplr6AWDPxI8qwJqw1rR1cPWj74=.62c0816f-f052-487f-9a57-d70e6200eda5@github.com>
 <YXvTxYHmIkh84GZW5VCxABkHJtjJ7nbAFwqcQz31fx8=.10d817a0-f3d3-4738-8ca5-47ba392344cf@github.com>
Message-ID: <MOGh664-aRd9ZyxQNfPuTxa1RaP2qdnKBIRmOu8rleE=.459ba5d6-ce71-4e46-92d1-c403d0c85160@github.com>

On Wed, 1 Jun 2022 01:04:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> In riscv, 'imm[31:28]? should be 'imm[31:20]' for '0x7ff' in the following two places:
>> 
>> src/hotspot/cpu/riscv/assembler_riscv.cpp:
>> 
>> 
>> void Assembler::li64(Register Rd, int64_t imm) {
>> // Load upper 32 bits. upper = imm[63:32], but if imm[31] == 1 or
>> // (imm[31:28] == 0x7ff && imm[19] == 1), upper = imm[63:32] + 1.
>> int64_t lower = imm & 0xffffffff;
>> 
>> 
>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp:
>> 
>> 
>>   // Load upper 32 bits. Upper = target[63:32], but if target[31] = 1 or (target[31:28] == 0x7ff && target[19] == 1),
>>   // upper = target[63:32] + 1.
>> 
>> 
>> This patch also unifies the immediate type in `movptr_with_offset` to `int64_t`.
>> 
>> Hotspot tier1 test on QEMU passed without new failures.
>
> Looks fine.

@RealFYang thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8950

From tschatzl at openjdk.java.net  Wed Jun  1 09:29:41 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Jun 2022 09:29:41 GMT
Subject: RFR: 8287215: Add method to scan bitmap backwards [v5]
In-Reply-To: <QGgIPrl0iCixQeG9skPvmOb82zcjnmgvzzKInbW0thI=.9cb654f9-3f27-4ee2-a9ab-c314cf637ee9@github.com>
References: <rK3j6q4vVEAcQWKBiTawunrzRpJED3kG58QmBPVUpUg=.7c924904-ba3f-48fe-a0a1-0962d1369ecc@github.com>
 <QGgIPrl0iCixQeG9skPvmOb82zcjnmgvzzKInbW0thI=.9cb654f9-3f27-4ee2-a9ab-c314cf637ee9@github.com>
Message-ID: <fLIytk38rsa2weJupbrrev4P4A_tYvnMAJ4zJjEsw0c=.85a97a2b-cc5f-430b-8b9d-d71e4df5ff8e@github.com>

On Mon, 30 May 2022 13:31:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708).
>> 
>> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself.
>> 
>> Testing: gtest
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

I am withdrawing this change because during review of the change that used this API we found that it is not necessary any more.

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

PR: https://git.openjdk.java.net/jdk/pull/8869

From tschatzl at openjdk.java.net  Wed Jun  1 09:29:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Jun 2022 09:29:42 GMT
Subject: Withdrawn: 8287215: Add method to scan bitmap backwards
In-Reply-To: <rK3j6q4vVEAcQWKBiTawunrzRpJED3kG58QmBPVUpUg=.7c924904-ba3f-48fe-a0a1-0962d1369ecc@github.com>
References: <rK3j6q4vVEAcQWKBiTawunrzRpJED3kG58QmBPVUpUg=.7c924904-ba3f-48fe-a0a1-0962d1369ecc@github.com>
Message-ID: <KAHTZIj55j8wbdOmxBudWZFQrATmb7o_-iiQqSpjgTo=.d845ab32-d08c-4665-aaf6-ad1fef319378@github.com>

On Tue, 24 May 2022 15:33:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708).
> 
> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself.
> 
> Testing: gtest
> 
> Thanks,
>   Thomas

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8869

From fjiang at openjdk.java.net  Wed Jun  1 09:33:36 2022
From: fjiang at openjdk.java.net (Feilong Jiang)
Date: Wed, 1 Jun 2022 09:33:36 GMT
Subject: Integrated: 8287552: riscv: Fix comment typo in li64
In-Reply-To: <t4vPXE5izZLNNDXAZplr6AWDPxI8qwJqw1rR1cPWj74=.62c0816f-f052-487f-9a57-d70e6200eda5@github.com>
References: <t4vPXE5izZLNNDXAZplr6AWDPxI8qwJqw1rR1cPWj74=.62c0816f-f052-487f-9a57-d70e6200eda5@github.com>
Message-ID: <OntaZG4PSsCmimH5KvJwXE3RJO9hT8Aqa78LyZLgOjU=.837d7980-5889-4469-aaee-e263086f3527@github.com>

On Tue, 31 May 2022 07:59:21 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

> In riscv, 'imm[31:28]? should be 'imm[31:20]' for '0x7ff' in the following two places:
> 
> src/hotspot/cpu/riscv/assembler_riscv.cpp:
> 
> 
> void Assembler::li64(Register Rd, int64_t imm) {
> // Load upper 32 bits. upper = imm[63:32], but if imm[31] == 1 or
> // (imm[31:28] == 0x7ff && imm[19] == 1), upper = imm[63:32] + 1.
> int64_t lower = imm & 0xffffffff;
> 
> 
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp:
> 
> 
>   // Load upper 32 bits. Upper = target[63:32], but if target[31] = 1 or (target[31:28] == 0x7ff && target[19] == 1),
>   // upper = target[63:32] + 1.
> 
> 
> This patch also unifies the immediate type in `movptr_with_offset` to `int64_t`.
> 
> Hotspot tier1 test on QEMU passed without new failures.

This pull request has now been integrated.

Changeset: 0ef3d855
Author:    Feilong Jiang <fjiang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ef3d8551d85c9004087464d656074dac753acfd
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8287552: riscv: Fix comment typo in li64

Co-authored-by: Dingli Zhang <dingli at iscas.ac.cn>
Reviewed-by: fyang

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

PR: https://git.openjdk.java.net/jdk/pull/8950

From shade at openjdk.java.net  Wed Jun  1 10:12:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 10:12:08 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*)
Message-ID: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>

Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 

Sample output generated by gtest:


Bitmap (0 bits):
Bitmap (128 bits):
    0: .......... .......... .......... .......... ..........
   50: .......... ....S..... .......... .......... ..........
  100: .......... .......... ........
Bitmap (1024 bits):
    0: .......... .......... .......... .......... ..........
   50: .......... .......... .......... .......... ..........
  100: .......... .......... .......... .......... ..........
  150: .......... .......... .......... .......... ..........
  200: .......... .......... .......... .......... ..........
  250: .......... .......... .......... .......... ..........
  300: .......... .......... .......... .......... ..........
  350: .......... .......... .......... .......... ..........
  400: .......... .......... .......... .......... ..........
  450: .......... .......... .......... .......... ..........
  500: .......... ..S....... .......... .......... ..........
  550: .......... .......... .......... .......... ..........
  600: .......... .......... .......... .......... ..........
  650: .......... .......... .......... .......... ..........
  700: .......... .......... .......... .......... ..........
  750: .......... .......... .......... .......... ..........
  800: .......... .......... .......... .......... ..........
  850: .......... .......... .......... .......... ..........
  900: .......... .......... .......... .......... ..........
  950: .......... .......... .......... .......... ..........
 1000: .......... .......... ....


It becomes clearer that bits 64 and 512 are set, respectively.

Additional testing:
 - [x] Linux x86_64 fastdebug, new gtest
 - [x] Linux x86_64 release, new gtest

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8970/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8970&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287661
  Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8970.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8970/head:pull/8970

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 10:15:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 10:15:36 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <_9szrwwasTwWD6ZQRRnt8eR7tLE685Hmi8eSK-XtkAM=.93186cc4-3e8f-4348-8e1a-13897c8a8255@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

I am okay with most of it, but still concerned with the injecting new code into hot marking loops.

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From shade at openjdk.java.net  Wed Jun  1 10:15:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 10:15:38 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
Message-ID: <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>

On Mon, 30 May 2022 07:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - NMethod::heal_nmethod() does not need to handle ref-update
>
> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:
> 
>> 71:     if (obj->is_instance()) {
>> 72:       // Case 1: Normal oop, process as usual.
>> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {
> 
> Ooof, this is very hot code path. Is there any way to do this without injecting the code here?

Um, this conversation seems to be "resolved" without the answer.

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From duke at openjdk.java.net  Wed Jun  1 11:59:36 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 1 Jun 2022 11:59:36 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Remove superfluous if stmt

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/af6ab81e..0b83cb44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From jvernee at openjdk.java.net  Wed Jun  1 11:59:37 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 1 Jun 2022 11:59:37 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
Message-ID: <zuCg7a4q8zVAhBw3gUmgHMQMi85qDhPLiu2ua3fECXA=.8aa34d94-0ee0-4bb1-bbe0-88d8483fd566@github.com>

On Wed, 1 Jun 2022 11:55:59 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous if stmt

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Wed Jun  1 11:59:41 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 1 Jun 2022 11:59:41 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v2]
In-Reply-To: <c0e5X-abIex-SgL6pd9tPtIHo-V1K4hCygDpz6w1MLw=.189bff16-edb0-4e1e-a609-eedf745ea683@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <CxQTnAqBFJaMnzjsumAB7EAdfNQBtltKtun73ydJ9ig=.db5c436f-93bd-4040-8644-71746ad14f29@github.com>
 <c0e5X-abIex-SgL6pd9tPtIHo-V1K4hCygDpz6w1MLw=.189bff16-edb0-4e1e-a609-eedf745ea683@github.com>
Message-ID: <wW9VFV_YjadTqyw0EhjRZ9dqFtl0iZOoRJLgaJ9kwHE=.bcef4c95-73c9-4b90-a411-4fee5c85ce5a@github.com>

On Tue, 31 May 2022 10:35:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change log to single line
>
> src/hotspot/share/runtime/deoptimization.cpp line 1939:
> 
>> 1937:       const char* reason_action = Deoptimization::trap_action_name(action);
>> 1938:       JFR_ONLY(post_deoptimization_event(nm, tm, trap_bci, trap_bc, reason, action);)
>> 1939:       if (Log(deoptimization)::is_info()) {
> 
> I don't think this `if` is needed now? The `log_debug` macro already seems to check whether the tag is enabled.

100% correct, it also checks the wrong log level so double whammy mistake right there.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From zgu at openjdk.java.net  Wed Jun  1 12:32:33 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 12:32:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
Message-ID: <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>

On Wed, 1 Jun 2022 10:10:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:
>> 
>>> 71:     if (obj->is_instance()) {
>>> 72:       // Case 1: Normal oop, process as usual.
>>> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {
>> 
>> Ooof, this is very hot code path. Is there any way to do this without injecting the code here?
>
> Um, this conversation seems to be "resolved" without the answer.

Hmm... somehow, my comments gone missing.

Yes, I am award of it, but could not find a better place, any suggestions are welcome.

ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).

Let's get this in for correctness and work on optimizing it in followup CR.

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From duke at openjdk.java.net  Wed Jun  1 13:01:38 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 1 Jun 2022 13:01:38 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
Message-ID: <keaGqdp3OSSiUbtw_YjlXZh4DlROLw--3zXaOVHS2Sc=.1819302a-8f78-4e96-be86-ec3b59fa5b0c@github.com>

On Wed, 1 Jun 2022 11:59:36 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous if stmt

@dholmes-ora , would you mind taking another look at this? I didn't address most of your concerns directly as the relevant code has been removed. Thanks :).

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From stefank at openjdk.java.net  Wed Jun  1 13:03:33 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 1 Jun 2022 13:03:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
Message-ID: <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>

On Wed, 1 Jun 2022 12:28:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Um, this conversation seems to be "resolved" without the answer.
>
> Hmm... somehow, my comments gone missing.
> 
> Yes, I am award of it, but could not find a better place, any suggestions are welcome.
> 
> ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).
> 
> Let's get this in for correctness and work on optimizing it in followup CR.
> 
> Thanks.

Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From zgu at openjdk.java.net  Wed Jun  1 13:50:37 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 13:50:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
 <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
Message-ID: <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>

On Wed, 1 Jun 2022 13:00:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hmm... somehow, my comments gone missing.
>> 
>> Yes, I am award of it, but could not find a better place, any suggestions are welcome.
>> 
>> ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).
>> 
>> Let's get this in for correctness and work on optimizing it in followup CR.
>> 
>> Thanks.
>
> Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.

Thanks for your insights, @stefank

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From rpressler at openjdk.java.net  Wed Jun  1 14:14:35 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Wed, 1 Jun 2022 14:14:35 GMT
Subject: Integrated: 8287233: Crash in Continuation.enterSpecial: stop: tried
 to execute native method as non-native
In-Reply-To: <yMwnynv2x_Xw-2JKkQG8wG_b2PehcC5GStj3YAZF1NA=.ddf3d025-6d00-4461-9acb-c09a7eec5cc6@github.com>
References: <yMwnynv2x_Xw-2JKkQG8wG_b2PehcC5GStj3YAZF1NA=.ddf3d025-6d00-4461-9acb-c09a7eec5cc6@github.com>
Message-ID: <lgGTTKXbVgxLIXY3qJMgIJ7_UoZeWLIz5q_txIPfnIw=.67cf60fe-708c-4fa1-b221-9cede0e1da8c@github.com>

On Fri, 27 May 2022 15:53:25 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial.
> 
> Passes Loom tiers 1-5.

This pull request has now been integrated.

Changeset: b2b4ee21
Author:    Ron Pressler <rpressler at openjdk.org>
Committer: Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2b4ee212f06c606fc51e03ff33642035f4a4328
Stats:     22 lines in 2 files changed: 12 ins; 3 del; 7 mod

8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native

Reviewed-by: dholmes, pchilanomate

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

PR: https://git.openjdk.java.net/jdk/pull/8926

From shade at openjdk.java.net  Wed Jun  1 14:49:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 14:49:32 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
 <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
 <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>
Message-ID: <lJpOuBmkdPXK676M85mbzNkqgSBYCYAlXwsU3saJuUA=.a4d01b93-c291-4c6c-949e-d72d0d3cb905@github.com>

On Wed, 1 Jun 2022 13:48:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.
>
> Thanks for your insights, @stefank

All right then!

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From shade at openjdk.java.net  Wed Jun  1 15:09:07 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:09:07 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
Message-ID: <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>

> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
> 
> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
> 
> Brief tour of changes:
>  - Check the incoming registers explicitly
>  - Pass explicit argument registers to `fill_continuation_entry`
>  - Use the usual `NativeCall` alignment code to produce a patchable call
>  - Check that static stub is emitted, fail hard otherwise
>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
 - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
 - Harmonize exception handler invocation
 - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
 - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
 - Revert test groups
 - Fix

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

Changes: https://git.openjdk.java.net/jdk/pull/8802/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=03
  Stats: 109 lines in 2 files changed: 50 ins; 15 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8802/head:pull/8802

PR: https://git.openjdk.java.net/jdk/pull/8802

From shade at openjdk.java.net  Wed Jun  1 15:48:37 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:48:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

I still have a question: now that closures drop `do_metadata`, does that mean we always traverse metadata now? Which means we can remove half of the closures? For example, `ShenandoahMarkUpdateRefsClosure` and `ShenandoahMarkUpdateRefsMetadataClosure` are pretty much the same, right? We can leave `ShenandoahMarkUpdateRefsClosure` only then?

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From stefank at openjdk.java.net  Wed Jun  1 15:49:45 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 1 Jun 2022 15:49:45 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*)
In-Reply-To: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
Message-ID: <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>

On Wed, 1 Jun 2022 10:04:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
> 
> Sample output generated by gtest:
> 
> 
> Bitmap (0 bits):
> Bitmap (128 bits):
>     0: .......... .......... .......... .......... ..........
>    50: .......... ....S..... .......... .......... ..........
>   100: .......... .......... ........
> Bitmap (1024 bits):
>     0: .......... .......... .......... .......... ..........
>    50: .......... .......... .......... .......... ..........
>   100: .......... .......... .......... .......... ..........
>   150: .......... .......... .......... .......... ..........
>   200: .......... .......... .......... .......... ..........
>   250: .......... .......... .......... .......... ..........
>   300: .......... .......... .......... .......... ..........
>   350: .......... .......... .......... .......... ..........
>   400: .......... .......... .......... .......... ..........
>   450: .......... .......... .......... .......... ..........
>   500: .......... ..S....... .......... .......... ..........
>   550: .......... .......... .......... .......... ..........
>   600: .......... .......... .......... .......... ..........
>   650: .......... .......... .......... .......... ..........
>   700: .......... .......... .......... .......... ..........
>   750: .......... .......... .......... .......... ..........
>   800: .......... .......... .......... .......... ..........
>   850: .......... .......... .......... .......... ..........
>   900: .......... .......... .......... .......... ..........
>   950: .......... .......... .......... .......... ..........
>  1000: .......... .......... ....
> 
> 
> It becomes clearer that bits 64 and 512 are set, respectively.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, new gtest
>  - [x] Linux x86_64 release, new gtest

Great that you found this!

src/hotspot/share/utilities/bitMap.cpp line 706:

> 704:   }
> 705:   st->cr();
> 706: }

I wonder if it wouldn't be more useful to use line and chunk sizes that are a power-of-two? Maybe if we find that that would be more useful, than we could later add a second function to support that.

test/hotspot/gtest/utilities/test_bitMap.cpp line 107:

> 105:       map.set_bit(size / 2);
> 106:     }
> 107:     map.print_on(tty);

I would prefer if we didn't print to tty here. I think we should try to stay away from printing out stuff in the gtest runs. (I know that some of the tests do it).

This can be easily fixed by printing to UL:

diff --git a/test/hotspot/gtest/utilities/test_bitMap.cpp b/test/hotspot/gtest/utilities/test_bitMap.cpp
index 7391d21ccc2..80404907e90 100644
--- a/test/hotspot/gtest/utilities/test_bitMap.cpp
+++ b/test/hotspot/gtest/utilities/test_bitMap.cpp
@@ -22,6 +22,7 @@
  */
 
 #include "precompiled.hpp"
+#include "logging/logStream.hpp"
 #include "memory/resourceArea.hpp"
 #include "utilities/bitMap.inline.hpp"
 #include "unittest.hpp"
@@ -104,7 +105,9 @@ class BitMapTest {
     if (size > 0) {
       map.set_bit(size / 2);
     }
-    map.print_on(tty);
+
+    LogStreamHandle(Info, test) stream;
+    map.print_on(&stream);
   }
 
 #endif


And if you want to see the output you can then just run with:

make test exploded-test-gtest GTEST="JAVA_OPTIONS=-Xlog:test;OPTIONS=--gtest_filter=BitMap*"

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

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 15:49:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:49:46 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*)
In-Reply-To: <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>
Message-ID: <XR-YaaY3hnX_v9x9wijRsWfNAkpcZB3qba-N2qiiQQI=.eea7f31b-2f4a-4505-b19c-7ba7118c4f18@github.com>

On Wed, 1 Jun 2022 15:05:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
>> 
>> Sample output generated by gtest:
>> 
>> 
>> Bitmap (0 bits):
>> Bitmap (128 bits):
>>     0: .......... .......... .......... .......... ..........
>>    50: .......... ....S..... .......... .......... ..........
>>   100: .......... .......... ........
>> Bitmap (1024 bits):
>>     0: .......... .......... .......... .......... ..........
>>    50: .......... .......... .......... .......... ..........
>>   100: .......... .......... .......... .......... ..........
>>   150: .......... .......... .......... .......... ..........
>>   200: .......... .......... .......... .......... ..........
>>   250: .......... .......... .......... .......... ..........
>>   300: .......... .......... .......... .......... ..........
>>   350: .......... .......... .......... .......... ..........
>>   400: .......... .......... .......... .......... ..........
>>   450: .......... .......... .......... .......... ..........
>>   500: .......... ..S....... .......... .......... ..........
>>   550: .......... .......... .......... .......... ..........
>>   600: .......... .......... .......... .......... ..........
>>   650: .......... .......... .......... .......... ..........
>>   700: .......... .......... .......... .......... ..........
>>   750: .......... .......... .......... .......... ..........
>>   800: .......... .......... .......... .......... ..........
>>   850: .......... .......... .......... .......... ..........
>>   900: .......... .......... .......... .......... ..........
>>   950: .......... .......... .......... .......... ..........
>>  1000: .......... .......... ....
>> 
>> 
>> It becomes clearer that bits 64 and 512 are set, respectively.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, new gtest
>>  - [x] Linux x86_64 release, new gtest
>
> src/hotspot/share/utilities/bitMap.cpp line 706:
> 
>> 704:   }
>> 705:   st->cr();
>> 706: }
> 
> I wonder if it wouldn't be more useful to use line and chunk sizes that are a power-of-two? Maybe if we find that that would be more useful, than we could later add a second function to support that.

My thought was that the *humans* would try to see where the set bits are, and so working in decimals is better? But we can do binary too, maybe grouping by 8 bits and 8 bytes per line would be quite natural.

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 15:56:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:56:39 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
Message-ID: <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>

> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
> 
> Sample output generated by gtest:
> 
> 
> [0.292s][info][test] Bitmap (0 bits):
> [0.292s][info][test] Bitmap (128 bits):
> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]    64: S....... ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test] Bitmap (1024 bits):
> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]    64: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   128: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   192: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   256: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   320: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   384: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   448: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   512: S....... ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   576: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   640: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   704: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   768: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   832: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   896: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   960: ........ ........ ........ ........ ........ ........ ........ ........
> 
> 
> It becomes clearer that bits 64 and 512 are set, respectively.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, new gtest
>  - [x] Linux x86_64 release, new gtest

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

 - Merge branch 'master' into JDK-8287661-bitmaps-improv
 - Review comments
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8970/files
  - new: https://git.openjdk.java.net/jdk/pull/8970/files/a9aaf61f..921f646a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8970&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8970&range=00-01

  Stats: 844 lines in 23 files changed: 321 ins; 416 del; 107 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8970.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8970/head:pull/8970

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 15:56:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:56:42 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <XR-YaaY3hnX_v9x9wijRsWfNAkpcZB3qba-N2qiiQQI=.eea7f31b-2f4a-4505-b19c-7ba7118c4f18@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>
 <XR-YaaY3hnX_v9x9wijRsWfNAkpcZB3qba-N2qiiQQI=.eea7f31b-2f4a-4505-b19c-7ba7118c4f18@github.com>
Message-ID: <GNtHEiUAB3uCvMx_QQEcFCv_o-UZ8LSR7w-ukTd5SqM=.1a1c15ba-cb41-4178-9efe-91cc7ec36aa5@github.com>

On Wed, 1 Jun 2022 15:47:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/utilities/bitMap.cpp line 706:
>> 
>>> 704:   }
>>> 705:   st->cr();
>>> 706: }
>> 
>> I wonder if it wouldn't be more useful to use line and chunk sizes that are a power-of-two? Maybe if we find that that would be more useful, than we could later add a second function to support that.
>
> My thought was that the *humans* would try to see where the set bits are, and so working in decimals is better? But we can do binary too, maybe grouping by 8 bits and 8 bytes per line would be quite natural.

Done, see new commit, and new PR body for the example.

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 15:56:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:56:45 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <TkJ0hnf0QEvx8CtdtGi_Dkk8vbEmhYW9BoTtGDLCgNY=.3e071b66-e43e-457b-94aa-3b0ae4b7a1f8@github.com>
Message-ID: <LJFMW1cu1HvTOIi4532OH8YNIkvuYQXH_nRJKuGUBN8=.b04c7133-9914-499a-b2db-9cf469689b51@github.com>

On Wed, 1 Jun 2022 15:44:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8287661-bitmaps-improv
>>  - Review comments
>>  - Fix
>
> test/hotspot/gtest/utilities/test_bitMap.cpp line 107:
> 
>> 105:       map.set_bit(size / 2);
>> 106:     }
>> 107:     map.print_on(tty);
> 
> I would prefer if we didn't print to tty here. I think we should try to stay away from printing out stuff in the gtest runs. (I know that some of the tests do it).
> 
> This can be easily fixed by printing to UL:
> 
> diff --git a/test/hotspot/gtest/utilities/test_bitMap.cpp b/test/hotspot/gtest/utilities/test_bitMap.cpp
> index 7391d21ccc2..80404907e90 100644
> --- a/test/hotspot/gtest/utilities/test_bitMap.cpp
> +++ b/test/hotspot/gtest/utilities/test_bitMap.cpp
> @@ -22,6 +22,7 @@
>   */
>  
>  #include "precompiled.hpp"
> +#include "logging/logStream.hpp"
>  #include "memory/resourceArea.hpp"
>  #include "utilities/bitMap.inline.hpp"
>  #include "unittest.hpp"
> @@ -104,7 +105,9 @@ class BitMapTest {
>      if (size > 0) {
>        map.set_bit(size / 2);
>      }
> -    map.print_on(tty);
> +
> +    LogStreamHandle(Info, test) stream;
> +    map.print_on(&stream);
>    }
>  
>  #endif
> 
> 
> And if you want to see the output you can then just run with:
> 
> make test exploded-test-gtest GTEST="JAVA_OPTIONS=-Xlog:test;OPTIONS=--gtest_filter=BitMap*"

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From zgu at openjdk.java.net  Wed Jun  1 16:00:47 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 16:00:47 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
 <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>
Message-ID: <XlZ5C8d1y-KCr7kl00zRFNR6_F6135cO7VCTHfwfXMQ=.f49b924e-0934-48d2-b456-a8967c619281@github.com>

On Wed, 1 Jun 2022 15:45:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ShenandoahMarkUpdateRefsMetadataClosure

Yes, we always walk metadata now.

And right, I need to look into duplicated closures. But can we do that in separate CR? Another round of tests going to take a couple of days, and I want to get this in before RDP1.

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From stefank at openjdk.java.net  Wed Jun  1 16:03:41 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 1 Jun 2022 16:03:41 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>
Message-ID: <No0_zEoieTaPBeRaqjynh0Exno3_27JGclbBWJJm48c=.a0244dd2-6e01-4490-be24-d9ec19f72432@github.com>

On Wed, 1 Jun 2022 15:56:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
>> 
>> Sample output generated by gtest:
>> 
>> 
>> [0.292s][info][test] Bitmap (0 bits):
>> [0.292s][info][test] Bitmap (128 bits):
>> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]    64: S....... ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test] Bitmap (1024 bits):
>> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]    64: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   128: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   192: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   256: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   320: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   384: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   448: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   512: S....... ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   576: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   640: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   704: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   768: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   832: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   896: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   960: ........ ........ ........ ........ ........ ........ ........ ........
>> 
>> 
>> It becomes clearer that bits 64 and 512 are set, respectively.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, new gtest
>>  - [x] Linux x86_64 release, new gtest
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8287661-bitmaps-improv
>  - Review comments
>  - Fix

Looks great! If we later change our mind about base 10 vs 2, we can revisit this.

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

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Wed Jun  1 16:13:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 16:13:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

All right then!

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8924

From duke at openjdk.java.net  Wed Jun  1 16:32:13 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Wed, 1 Jun 2022 16:32:13 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods' heap
Message-ID: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>

8263377: Store method handle linkers in the 'non-nmethods' heap

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

Commit messages:
 - Add PrintCodeCache support
 - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics
 - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics
 - Move to RuntimeBlob
 - Merge branch 'master' of https://github.com/yftsai/jdk into intrinsics
 - Move MHI to BufferBlob
 - Change _code to CodeBlob
 - minimize changes
 - Move MH intrinsics from CompiledMethod
 - Fix x86 build
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/f5bbade9...63771d64

Changes: https://git.openjdk.java.net/jdk/pull/8760/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8760&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263377
  Stats: 575 lines in 44 files changed: 295 ins; 172 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8760/head:pull/8760

PR: https://git.openjdk.java.net/jdk/pull/8760

From jvernee at openjdk.java.net  Wed Jun  1 16:32:14 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 1 Jun 2022 16:32:14 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <9jR-kROEq6brgypGGmgNBQWClxTd2BiAZ09prtI2VDk=.adf3cb55-8652-4f79-be8b-a78faef8c6ed@github.com>

On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8263377: Store method handle linkers in the 'non-nmethods' heap

src/hotspot/share/code/codeBlob.hpp line 468:

> 466:   MethodHandleIntrinsicBlob(Method* method, int mhi_size, CodeBuffer *code_buffer);
> 467: 
> 468:   Method*   _method;

Sorry, I know that this is still a draft (I was taking a sneak peak), but note that `BufferBlob` subclasses have a fixed header size `sizeof(BufferBlob)` (see the `BufferBlob` constructor in codeBlob.cpp).

Adding a field here can lead to the the start of the code section being overwritten. Just FYI, in case you were encountering any weird bugs.

I think the right move, if you want to add a field here, is to extend `RuntimeBlob` directly, and pass the right header size to the super constructor (or pass the right header size from all `BufferBlob` subclasses).

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From duke at openjdk.java.net  Wed Jun  1 16:32:14 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Wed, 1 Jun 2022 16:32:14 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <9jR-kROEq6brgypGGmgNBQWClxTd2BiAZ09prtI2VDk=.adf3cb55-8652-4f79-be8b-a78faef8c6ed@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <9jR-kROEq6brgypGGmgNBQWClxTd2BiAZ09prtI2VDk=.adf3cb55-8652-4f79-be8b-a78faef8c6ed@github.com>
Message-ID: <sCZh2xdkMUjVh7cZ4kxRrNfweRzPci3KluKPCXX6NUs=.cf78bfed-778d-4cc4-af96-dd3bac544258@github.com>

On Wed, 18 May 2022 13:19:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 8263377: Store method handle linkers in the 'non-nmethods' heap
>
> src/hotspot/share/code/codeBlob.hpp line 468:
> 
>> 466:   MethodHandleIntrinsicBlob(Method* method, int mhi_size, CodeBuffer *code_buffer);
>> 467: 
>> 468:   Method*   _method;
> 
> Sorry, I know that this is still a draft (I was taking a sneak peak), but note that `BufferBlob` subclasses have a fixed header size `sizeof(BufferBlob)` (see the `BufferBlob` constructor in codeBlob.cpp).
> 
> Adding a field here can lead to the the start of the code section being overwritten. Just FYI, in case you were encountering any weird bugs.
> 
> I think the right move, if you want to add a field here, is to extend `RuntimeBlob` directly, and pass the right header size to the super constructor (or pass the right header size from all `BufferBlob` subclasses).

Thanks for catching the bug.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From aph at openjdk.java.net  Wed Jun  1 16:43:36 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 1 Jun 2022 16:43:36 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
 <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
Message-ID: <cSCiF_4hpIS1gpZvVpALB73LAehE2f1GqsrTJUslIxc=.bf0ac3df-cb7b-437c-9521-91e7880b48dc@github.com>

On Wed, 1 Jun 2022 07:32:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> Is there any advantage to having the first instruction be "nop" instead of a branch that skips over the movks?
>>> 
>>> ```
>>> b done
>>> movk zr, lo
>>> movk zr, hi
>>> done:
>>> ```
>>> 
>>> I was going to suggest:
>>> 
>>> ```
>>>  b done
>>>  (raw data)
>>>  done:
>>> ```
>>> 
>>> but then it might be hard for NativePostCallNop::check() to prevent false positives.
>> 
>> The NOP is required for deoptimization.
>
>> The NOP is required for deoptimization.
> 
> I could be wrong, but I thought aarch64 allowed undefined instructions to be patched on top of branch instructions too.

@dean-long , are you happy with that explanation?

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From zgu at openjdk.java.net  Wed Jun  1 17:04:37 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 17:04:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
 <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>
Message-ID: <VlLjMFN6q8pJwxJ2vQfmxOOMKZyU7apAqG5sfS87JHM=.8e45c2d5-0b5e-4520-bf32-787246f28190@github.com>

On Wed, 1 Jun 2022 16:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - NMethod::heal_nmethod() does not need to handle ref-update
>
> All right then!

Thanks, @shipilev

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From zgu at openjdk.java.net  Wed Jun  1 17:04:39 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 17:04:39 GMT
Subject: Integrated: 8286829: Shenandoah: fix Shenandoah Loom support
In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
Message-ID: <NNN4yZJQT1k9NJwGkE0jik5754JaDtA0NOVd9gniPHk=.a24ec7d8-80d2-43bc-b063-ccc391afb032@github.com>

On Fri, 27 May 2022 14:52:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review the patch that fixes Loom support in Shenandoah GC.
> 
> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
> 
> Test:  
> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
> - [x] hotspot_gc_shenandoah  on Linux x86_32
> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)

This pull request has now been integrated.

Changeset: 239ac2a5
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/239ac2a5d4c9a13e10e8c75324cd51f5f825337d
Stats:     112 lines in 15 files changed: 77 ins; 7 del; 28 mod

8286829: Shenandoah: fix Shenandoah Loom support

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/8924

From dcubed at openjdk.java.net  Wed Jun  1 19:03:33 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 1 Jun 2022 19:03:33 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <i76P-S1MhaLuhf1bo8Auin3euckzQ1ALvd9X53GGOVY=.0cbd7d21-a0aa-4cb1-aaa7-2eab59acad97@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Before Loom, there was a TLH in the outer JVM/TI SuspendThread() entry point
so the current thread was already protected. Here's the relevant code from
build/macosx-x86_64-normal-server-release/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp
in JDK18:


static jvmtiError JNICALL
jvmti_SuspendThread(jvmtiEnv* env,
            jthread thread) {

#if !INCLUDE_JVMTI 
  return JVMTI_ERROR_NOT_AVAILABLE; 
#else 
  if(!JvmtiEnv::is_vm_live()) {
    return JVMTI_ERROR_WRONG_PHASE;
  }
  Thread* this_thread = Thread::current_or_null(); 
  if (this_thread == NULL || !this_thread->is_Java_thread()) {
    return JVMTI_ERROR_UNATTACHED_THREAD;
  }
  JavaThread* current_thread = JavaThread::cast(this_thread);
  MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, current_thread));
  ThreadInVMfromNative __tiv(current_thread);
  VM_ENTRY_BASE(jvmtiError, jvmti_SuspendThread , current_thread)
  debug_only(VMNativeEntryWrapper __vew;)
  PreserveExceptionMark __em(this_thread);
  JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env);
  if (!jvmti_env->is_valid()) {
    return JVMTI_ERROR_INVALID_ENVIRONMENT;
  }

  if (jvmti_env->get_capabilities()->can_suspend == 0) {
    return JVMTI_ERROR_MUST_POSSESS_CAPABILITY;
  }
  jvmtiError err;
  JavaThread* java_thread = NULL;
  ThreadsListHandle tlh(this_thread);
  if (thread == NULL) {
    java_thread = current_thread;
  } else {
    err = JvmtiExport::cv_external_thread_to_JavaThread(tlh.list(), thread, &java_thread, NULL);
    if (err != JVMTI_ERROR_NONE) {
      return err;
    }
  }
  err = jvmti_env->SuspendThread(java_thread);
  return err;
#endif // INCLUDE_JVMTI
}


so it was definitely my intent that the current thread be protected
by the TLH that was in the entry code. Yes, that protection is not
needed, but that's the way I implemented it when
is_JavaThread_protected_by_TLH() was added to the system.

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From dlong at openjdk.java.net  Wed Jun  1 20:21:35 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 1 Jun 2022 20:21:35 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
Message-ID: <O55L08pHL_GuiyYNPaUeyKvwQEVMOT1K1tyojBY6K3s=.02b44024-3fc4-4061-ab4c-90df5e6fbb49@github.com>

On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. 
> 
> I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed.

Marked as reviewed by dlong (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From coleenp at openjdk.java.net  Wed Jun  1 20:26:41 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Jun 2022 20:26:41 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
Message-ID: <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>

On Mon, 23 May 2022 17:13:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable
>> 
>> - `template<typename F> void ResourceHashtable::iterate(F f)`
>> - `template<typename F> void ResourceHashtable::iterate_all(F f)`
>> 
>> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality.
>> 
>> Testing with tiers 1-4.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some clean up suggested by @stefank

I'm  a bit baffled by the layers of lambda expressions.

src/hotspot/share/cds/dumpTimeClassInfo.hpp line 209:

> 207:     } else {
> 208:       return _unregistered_count;
> 209:     }

This file has a blank first line, can you fix this?

src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp line 76:

> 74:     return iter->do_entry(k, v);
> 75:   };
> 76:   iterate(function);

I don't understand this wrapper level.  Why doesn't this call into the resourceHashtable::iterate function directly?  Same with the iterate_all function?

src/hotspot/share/classfile/systemDictionaryShared.cpp line 665:

> 663:     ResourceMark rm;
> 664:     UnregisteredClassesDuplicationChecker dup_checker;
> 665:     _dumptime_table->iterate(&dup_checker);

Which iterate function does this call?

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From coleenp at openjdk.java.net  Wed Jun  1 20:26:43 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Jun 2022 20:26:43 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>
Message-ID: <lGZzOF1bG3ul7RWmdA9fiIP8NVgmC1hc9G5xYBnbC3c=.3507175c-352d-4bdb-ac41-07de9fd19957@github.com>

On Wed, 1 Jun 2022 20:07:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some clean up suggested by @stefank
>
> src/hotspot/share/cds/dumpTimeClassInfo.hpp line 209:
> 
>> 207:     } else {
>> 208:       return _unregistered_count;
>> 209:     }
> 
> This file has a blank first line, can you fix this?

And no new line between these here:
#define SHARED_CDS_DUMPTIMESHAREDCLASSINFO_HPP
#include "cds/archiveBuilder.hpp"

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From dlong at openjdk.java.net  Wed Jun  1 20:32:26 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 1 Jun 2022 20:32:26 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
 <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
Message-ID: <ho5tr8ENbiIHydK8mxWUx7s-0cYPwmjCAVkT_l0tz3w=.fa1a2b4f-567d-4f1e-8452-fda4da670f96@github.com>

On Wed, 1 Jun 2022 07:32:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> Is there any advantage to having the first instruction be "nop" instead of a branch that skips over the movks?
>>> 
>>> ```
>>> b done
>>> movk zr, lo
>>> movk zr, hi
>>> done:
>>> ```
>>> 
>>> I was going to suggest:
>>> 
>>> ```
>>>  b done
>>>  (raw data)
>>>  done:
>>> ```
>>> 
>>> but then it might be hard for NativePostCallNop::check() to prevent false positives.
>> 
>> The NOP is required for deoptimization.
>
>> The NOP is required for deoptimization.
> 
> I could be wrong, but I thought aarch64 allowed undefined instructions to be patched on top of branch instructions too.

> @dean-long , are you happy with that explanation?

Yes, and thanks for the interesting performance data.  I had an ulterior motive for my question.  I was hoping there would be a platform-independent pattern that new ports could use initially, then optimize later. I think the

 b done
 (raw data)
 done:

pattern will work as long as call sites without a post-call NOP disambiguate by using a regular NOP.  Then NativePostCallNop::check() will only see either a NOP or a branch.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From sviswanathan at openjdk.java.net  Wed Jun  1 22:34:43 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 22:34:43 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
Message-ID: <W1vfSjOi96GVQBbaO5lsuV4q1uNafDtpKEIOfLlE2Gg=.f24283d4-66f2-40d3-9f85-f0c038315914@github.com>

On Fri, 13 May 2022 08:58:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
>> 
>>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>>   ** missing constant: offsetInRange=Parm
>>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
>> 
>> 
>> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).
>
> You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help!

@XiaohongGong Could you please rebase the branch and resolve conflicts?

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sviswanathan at openjdk.java.net  Wed Jun  1 23:36:02 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 23:36:02 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on Cascade
 Lake
Message-ID: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>

We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
The performance regression is due to auto-vectorization of small loops. 
We don?t have AVX3Threshold consideration in auto-vectorization. 
The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.

This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.

Please review.

Best Regard,
Sandhya

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

Commit messages:
 - x86 build fix
 - Fix 32-bit build
 - review comment resolution
 - Change option name and add checks
 - Limit auto vectorization to 32 byte vector on Cascade Lake

Changes: https://git.openjdk.java.net/jdk/pull/8877/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287697
  Stats: 53 lines in 6 files changed: 45 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8877/head:pull/8877

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Wed Jun  1 23:36:03 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 1 Jun 2022 23:36:03 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <BfVerk44QGXln_vr5RS1XaVL9ViDa7rkK2LQX9NTQFA=.40c65d49-ea71-43d1-aef8-a639b89c7bbd@github.com>

On Wed, 25 May 2022 01:48:16 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

You have trailing white spaces.

src/hotspot/share/opto/vectornode.cpp line 1280:

> 1278:       (vlen > 1) && is_power_of_2(vlen) &&
> 1279:       Matcher::vector_size_supported(bt, vlen) &&
> 1280:       (vlen * type2aelembytes(bt) <= SuperWordMaxVectorSize)) {

Can you put this whole condition into separate `static bool VectorNode::vector_size_supported(vlen, bt)` and use in both cases?

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From jbhateja at openjdk.java.net  Wed Jun  1 23:36:03 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 1 Jun 2022 23:36:03 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <7QY-uFABXZhtfKn103X1lZU8sJT3KayRAbeyQ21xfK4=.cadebd12-a765-4371-abad-3549050bfb2c@github.com>

On Wed, 25 May 2022 01:48:16 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

Vectorization through SLP can be controlled by constraining MaxVectorSize and through Vector APIs using narrower SPECIES. 
Can you kindly share more details on need for a separate SuperWordMaxVectorSize here. User already has all the necessary controls to limit C2 vector length, it will rarely happen that one want to emit 512 vector code using vector APIs and still limit auto-vectorizer to infer 256 bit vector operations and vice-versa. May be we should pessimistically just constrain the vector size of those loops which may result into AVX512 heavy instructions through a target specific analysis pass.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Wed Jun  1 23:39:13 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 23:39:13 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake
In-Reply-To: <BfVerk44QGXln_vr5RS1XaVL9ViDa7rkK2LQX9NTQFA=.40c65d49-ea71-43d1-aef8-a639b89c7bbd@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <BfVerk44QGXln_vr5RS1XaVL9ViDa7rkK2LQX9NTQFA=.40c65d49-ea71-43d1-aef8-a639b89c7bbd@github.com>
Message-ID: <37EIgoOQtTvySNmd1Q6hDs7JZku4UP2DAioShKwmPKs=.390e011b-3fda-48d7-bfe8-b9d260ca0822@github.com>

On Fri, 27 May 2022 04:05:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> You have trailing white spaces.

@vnkozlov Your review comments are resolved.
@jatin-bhateja  This is a simple fix for the problem in the short time frame that we have for the upcoming feature freeze. A more complex fix to enhance auto-vectorizer is a good thought.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Wed Jun  1 23:45:37 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 23:45:37 GMT
Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs
In-Reply-To: <NKq0VzAenxsK3zecPlM4VWDs9Fvx5XHO2h7apv4ZagQ=.23d5bb3a-8d06-462b-bcf2-7e7dff22617a@github.com>
References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com>
 <NKq0VzAenxsK3zecPlM4VWDs9Fvx5XHO2h7apv4ZagQ=.23d5bb3a-8d06-462b-bcf2-7e7dff22617a@github.com>
Message-ID: <NdBcEFVy7aJ6VidmqGuXTMy9qUchpGGHBno8ZCkQUbA=.e87b4ce8-b0de-4a02-805c-dc14a21d27ea@github.com>

On Tue, 24 May 2022 00:33:22 GMT, olivergillespie <duke at openjdk.java.net> wrote:

>> The current code already does this for 'older' Skylake processors,
>> namely those with _stepping < 5. My testing indicates this is a
>> problem for later processors in this family too, so I have removed the
>> max stepping condition.
>> 
>> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092.
>> 
>> A general description of the overall issue is given at
>> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking.
>> 
>> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID,
>> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7,
>> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using
>> -XX:UseAVX=3, along with a corresponding performance reduction.
>> 
>> I first saw this issue in a real production workload, where the main AVX3 instructions
>> being executed were those generated for various flavours of disjoint_arraycopy.
>> 
>> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark.
>> 
>> 
>> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \
>> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \
>> -jar SPECjvm2008.jar -ikv -ict xml.transform
>> 
>> 
>> Before the change, or with -XX:UseAVX=3:
>> 
>> 
>> Valid run!
>> Score on xml.transform: 776.00 ops/m
>> 
>> 
>> After the change, or with -XX:UseAVX=2:
>> 
>> 
>> Valid run!
>> Score on xml.transform: 894.07 ops/m
>> 
>> 
>> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively
>> affected by this change, but I contend that this is still the right move given the stark
>> difference in this benchmark combined with the fact that use of AVX3 instructions can
>> affect *all* processes/code on the host due to the downclocking, and the fact that this
>> effect is very hard to root-cause, for example CPU profiles look very similar before and
>> after since all code is equally slowed.
>
> Thanks for all the help so far. Is there anything I can help with?

@olivergillespie In our analysis of mpegaudio, we found that the problem was due to auto-vectorizer kicking in for small array initialization. The auto-vectorization does not take into consideration AVX3Threshold. I have submitted a simple PR to answer your concerns https://github.com/openjdk/jdk/pull/8877. Please take a look. The PR limits the auto-vectorizer to 256-bit or 32-byte for Cascade Lake.

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

PR: https://git.openjdk.java.net/jdk/pull/8731

From sviswanathan at openjdk.java.net  Wed Jun  1 23:57:26 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 1 Jun 2022 23:57:26 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

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

 - Merge branch 'master' into maxvector
 - x86 build fix
 - Fix 32-bit build
 - review comment resolution
 - Change option name and add checks
 - Limit auto vectorization to 32 byte vector on Cascade Lake

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8877/files
  - new: https://git.openjdk.java.net/jdk/pull/8877/files/d677fd9a..7f4c41e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=00-01

  Stats: 74281 lines in 805 files changed: 25008 ins; 42847 del; 6426 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8877/head:pull/8877

PR: https://git.openjdk.java.net/jdk/pull/8877

From jrose at openjdk.java.net  Thu Jun  2 00:39:34 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Thu, 2 Jun 2022 00:39:34 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
Message-ID: <5-F1LnpCoaba08VjMSE9Rnfy_hlQV3NI0TSHKXCzeKA=.c98e71bb-b201-4f57-aad3-d9519ba5b6ba@github.com>

On Wed, 1 Jun 2022 11:59:36 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous if stmt

>  In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization.

That trace-level information has a variable number of backtrace records in it:

https://github.com/openjdk/jdk/blob/6030c0e4033655e7ce282f43c2216b4e29411c22/src/hotspot/share/runtime/deoptimization.cpp#L1567

UL support for TraceDeoptimization will need to ensure that these complex aggregate events, consisting of multiple UL lines, are kept together.  Normal JVM concurrency will (otherwise) occasionally damage the TraceDeoptimization by interleaving individual UL lines that belong to separate complex aggregate events.

I note that you started with a multi-line format at the top of this PR, and went somewhere else.  Good move, but it only works until we need to output a variable amount of supporting event detail.

The integration of https://github.com/openjdk/jdk/pull/8748 is a *big* step in that direction.

FTR here are some notes from me about how existing complex output from HotSpot stresses the boundaries of UL:

https://bugs.openjdk.java.net/browse/JDK-8046148?focusedCommentId=13568278&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13568278

Good work.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From kvn at openjdk.java.net  Thu Jun  2 01:20:28 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 01:20:28 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
Message-ID: <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>

On Wed, 1 Jun 2022 23:57:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into maxvector
>  - x86 build fix
>  - Fix 32-bit build
>  - review comment resolution
>  - Change option name and add checks
>  - Limit auto vectorization to 32 byte vector on Cascade Lake

I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.

That may be preferable "simple fix" vs suggested changes for "short term solution".

The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.

BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From xgong at openjdk.java.net  Thu Jun  2 01:52:35 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 01:52:35 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
Message-ID: <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>

On Fri, 13 May 2022 08:58:12 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
>> 
>>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>>   ** missing constant: offsetInRange=Parm
>>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
>> 
>> 
>> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).
>
> You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help!

> @XiaohongGong Could you please rebase the branch and resolve conflicts?

Sure, I'm working on this now. The patch will be updated soon. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu Jun  2 03:27:59 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 03:27:59 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'jdk:master' into JDK-8283667
 - Use integer constant for offsetInRange all the way through
 - Rename "use_predicate" to "needs_predicate"
 - Rename the "usePred" to "offsetInRange"
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

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

Changes: https://git.openjdk.java.net/jdk/pull/8035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=04
  Stats: 447 lines in 43 files changed: 168 ins; 21 del; 258 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu Jun  2 03:28:00 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 2 Jun 2022 03:28:00 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
Message-ID: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>

On Thu, 2 Jun 2022 01:49:10 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
> 
> Sure, I'm working on this now. The patch will be updated soon. Thanks.

Resolved the conflicts. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sviswanathan at openjdk.java.net  Thu Jun  2 04:34:27 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 04:34:27 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

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

  Change SuperWordMaxVectorSize to develop option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8877/files
  - new: https://git.openjdk.java.net/jdk/pull/8877/files/7f4c41e2..e8ea837a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Thu Jun  2 04:41:35 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 04:41:35 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
Message-ID: <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>

On Thu, 2 Jun 2022 01:16:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into maxvector
>>  - x86 build fix
>>  - Fix 32-bit build
>>  - review comment resolution
>>  - Change option name and add checks
>>  - Limit auto vectorization to 32 byte vector on Cascade Lake
>
> I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.
> 
> That may be preferable "simple fix" vs suggested changes for "short term solution".
> 
> The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
> Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.
> 
> BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.

@vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kbarrett at openjdk.java.net  Thu Jun  2 05:13:24 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 2 Jun 2022 05:13:24 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <m3DR3mzjZ9LB0kvBXGefk7yJ0TP1xdfhXFEm2qTrYaI=.4721e8c0-a550-4dbd-8473-b4f5d8e06d01@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <OjV4X6TYDwZ9lMkA6wi0gSiBPtPJKlu_B4zeTbzIFdo=.e27c0b9a-22a0-4a6b-a73f-de0df794227c@github.com>
 <nR35jxHow0rqnRxJXUWLee22utffmhA-QoE_t3CyOCQ=.772398b7-6833-4ca0-a94a-18272d7e04b4@github.com>
 <m3DR3mzjZ9LB0kvBXGefk7yJ0TP1xdfhXFEm2qTrYaI=.4721e8c0-a550-4dbd-8473-b4f5d8e06d01@github.com>
Message-ID: <dEw_BNTJajQ69GlNySwGWyrd0MtM7SpUHuuhsNi3o4g=.7be3680f-9e4a-40df-a9b5-d7203e505f94@github.com>

On Wed, 25 May 2022 06:28:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is still needed as there are many places that use the old style iteration. Also, when the body of the iteration is complex, it might be more readable to do it as a separate class. E.g., here in systemDictionaryShared.cpp:
>> 
>> 
>>     UnregisteredClassesDuplicationChecker dup_checker;
>>     _dumptime_table->iterate(&dup_checker);
>> 
>> 
>> I think there's no ambiguity because `iter->do_entry()` cannot be substituted with the other template, and `function(node->_key, node->_value)` in the other template cannot be substituted here. So by SFINAE the C++ compiler can pick the correct template.
>
> Interesting. I got problems when I converted BitMap to support both closures and lambdas. The problem might have been that the iterate function took an specific closure class, and didn't use a template.

[Not a review, just a drive-by comment]
SFINAE operates on arguments and signatures; it doesn't reach into the bodies
of (potential) callees like that. The disambiguation is happening because one
argument (the Closure object) is passed as a pointer, while the other is a
lambda object (not a pointer). In the pointer to closure object case the ITER*
overload is a better match, so is selected. In the lambda case, it's not a
pointer so only the non-pointer overload is applicable.

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From kbarrett at openjdk.java.net  Thu Jun  2 05:13:24 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 2 Jun 2022 05:13:24 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <dEw_BNTJajQ69GlNySwGWyrd0MtM7SpUHuuhsNi3o4g=.7be3680f-9e4a-40df-a9b5-d7203e505f94@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <OjV4X6TYDwZ9lMkA6wi0gSiBPtPJKlu_B4zeTbzIFdo=.e27c0b9a-22a0-4a6b-a73f-de0df794227c@github.com>
 <nR35jxHow0rqnRxJXUWLee22utffmhA-QoE_t3CyOCQ=.772398b7-6833-4ca0-a94a-18272d7e04b4@github.com>
 <m3DR3mzjZ9LB0kvBXGefk7yJ0TP1xdfhXFEm2qTrYaI=.4721e8c0-a550-4dbd-8473-b4f5d8e06d01@github.com>
 <dEw_BNTJajQ69GlNySwGWyrd0MtM7SpUHuuhsNi3o4g=.7be3680f-9e4a-40df-a9b5-d7203e505f94@github.com>
Message-ID: <8cR-neKResMLcTtZE3_6rreY-m60SD4R_C9BX4zVhbA=.fb14951f-a749-4bfc-8ba6-0f63aac7199a@github.com>

On Thu, 2 Jun 2022 05:08:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Interesting. I got problems when I converted BitMap to support both closures and lambdas. The problem might have been that the iterate function took an specific closure class, and didn't use a template.
>
> [Not a review, just a drive-by comment]
> SFINAE operates on arguments and signatures; it doesn't reach into the bodies
> of (potential) callees like that. The disambiguation is happening because one
> argument (the Closure object) is passed as a pointer, while the other is a
> lambda object (not a pointer). In the pointer to closure object case the ITER*
> overload is a better match, so is selected. In the lambda case, it's not a
> pointer so only the non-pointer overload is applicable.

(And SFINAE _can't_ reach into the body like that, since the body might not be available.)

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From kvn at openjdk.java.net  Thu Jun  2 05:28:34 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 05:28:34 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
Message-ID: <j8-0UXLcvPT6L3AWtG6H2b6anlNU1nfWtJRDh2irio8=.725b1514-50d9-4c94-aea0-72bad5e9802d@github.com>

On Thu, 2 Jun 2022 04:34:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change SuperWordMaxVectorSize to develop option

Changes look good. I will start testing it.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Thu Jun  2 05:28:39 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 05:28:39 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
Message-ID: <WdznKT8gvzlcChNncZRs6ABkc4ipXBYq3Ja-s-MTR1E=.7f99497c-43d8-42a5-a705-81dfb9b88b6a@github.com>

On Thu, 2 Jun 2022 01:16:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into maxvector
>>  - x86 build fix
>>  - Fix 32-bit build
>>  - review comment resolution
>>  - Change option name and add checks
>>  - Limit auto vectorization to 32 byte vector on Cascade Lake
>
> I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.
> 
> That may be preferable "simple fix" vs suggested changes for "short term solution".
> 
> The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
> Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.
> 
> BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.

> @vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.

Thank you for checking stubs code.

We still have to run performance testing with this patch. We need only additional run with `MaxVectorSize=32` to compare results.

And I want @jatin-bhateja to approve this change too. Or give better suggestion.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From jbhateja at openjdk.java.net  Thu Jun  2 05:42:36 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 2 Jun 2022 05:42:36 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
Message-ID: <Q24GnLl48d15C2GtQBMpmDZegvMwVtteEp7SscbVM2A=.e71e8237-671b-4b71-8265-0c0d62190c4b@github.com>

On Thu, 2 Jun 2022 04:34:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change SuperWordMaxVectorSize to develop option

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

> 1304:       // Limit auto vectorization to 256 bit (32 byte) by default on Cascade Lake
> 1305:       FLAG_SET_DEFAULT(SuperWordMaxVectorSize, 32);
> 1306:     } else {

SuperWordMaxVectorSize is set to 32 bytes by default, it should still be capped by MaxVectorSize, in case user sets MaxVectorSize to 16 bytes.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From jbhateja at openjdk.java.net  Thu Jun  2 05:50:31 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 2 Jun 2022 05:50:31 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <WdznKT8gvzlcChNncZRs6ABkc4ipXBYq3Ja-s-MTR1E=.7f99497c-43d8-42a5-a705-81dfb9b88b6a@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <WdznKT8gvzlcChNncZRs6ABkc4ipXBYq3Ja-s-MTR1E=.7f99497c-43d8-42a5-a705-81dfb9b88b6a@github.com>
Message-ID: <x88NGIb779kvDFoyzaD7ZXYVE-DFJ6eBeUg8SsSFSgs=.f7ee9010-d5d2-443c-ae69-70e572219ac4@github.com>

On Thu, 2 Jun 2022 05:24:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.
>> 
>> That may be preferable "simple fix" vs suggested changes for "short term solution".
>> 
>> The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
>> Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.
>> 
>> BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.
>
>> @vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.
> 
> Thank you for checking stubs code.
> 
> We still have to run performance testing with this patch. We need only additional run with `MaxVectorSize=32` to compare results.
> 
> And I want @jatin-bhateja to approve this change too. Or give better suggestion.

> @vnkozlov Your review comments are resolved. @jatin-bhateja This is a simple fix for the problem in the short time frame that we have for the upcoming feature freeze. A more complex fix to enhance auto-vectorizer is a good thought.

Hi @sviswa7 . This looks reasonable since stubs and some macro assembly routines anyways operate under thresholds and does not strictly comply with max vector size.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Thu Jun  2 05:50:35 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 05:50:35 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
Message-ID: <6_2nfX-6yq4hxYp5OTnmmfO0WqSTJQcilG4N7tVN58o=.e5287dfa-2d07-4437-807e-71fd8fc6cffd@github.com>

On Thu, 2 Jun 2022 04:34:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change SuperWordMaxVectorSize to develop option

src/hotspot/share/opto/c2_globals.hpp line 85:

> 83:           range(0, max_jint)                                                \
> 84:                                                                             \
> 85:   develop(intx, SuperWordMaxVectorSize, 64,                                 \

The flag can't be develop because it is used in product code. It should be `diagnostic`.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Thu Jun  2 06:25:27 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 06:25:27 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <Q24GnLl48d15C2GtQBMpmDZegvMwVtteEp7SscbVM2A=.e71e8237-671b-4b71-8265-0c0d62190c4b@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
 <Q24GnLl48d15C2GtQBMpmDZegvMwVtteEp7SscbVM2A=.e71e8237-671b-4b71-8265-0c0d62190c4b@github.com>
Message-ID: <AvXmIhvb4lR_AMdCmK3dg2ip7uVXZfYbX02zAgGcNeM=.e1925ced-41d1-4697-b1fa-82f223dde5b6@github.com>

On Thu, 2 Jun 2022 05:38:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change SuperWordMaxVectorSize to develop option
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 1306:
> 
>> 1304:       // Limit auto vectorization to 256 bit (32 byte) by default on Cascade Lake
>> 1305:       FLAG_SET_DEFAULT(SuperWordMaxVectorSize, 32);
>> 1306:     } else {
> 
> SuperWordMaxVectorSize is set to 32 bytes by default, it should still be capped by MaxVectorSize, in case user sets MaxVectorSize to 16 bytes.

Yes. I submitted testing with `FLAG_SET_DEFAULT(SuperWordMaxVectorSize, MIN2(MaxVectorSize, (intx)32));`
And the flag declared as `DIAGNOSTIC` - product build fail otherwise.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From alanb at openjdk.java.net  Thu Jun  2 06:41:30 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 06:41:30 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
 <izG3NXAW6NwCwmQTofA082c5UWWdI7gfJe9gte1MHFY=.08f0d8a1-5c24-4f8c-bbd0-d334db7a9966@github.com>
Message-ID: <rUgQ27CwqqyovTcSRmPPnKVmoVfaxFQjFe0s2TMq77Q=.822ddd3c-5d0e-42db-87f0-b3b3651fabc8@github.com>

On Wed, 1 Jun 2022 06:26:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Fixed another typo in comment
>>  - Merge
>>  - Fix typos in comments
>>  - Allowing linking without intrinsic stub, contributed-by: rehn
>>  - Continuation clinit should fail if no continuations support
>>  - Fix merge issue with test
>>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>>  - Update
>>  - Expend test coverage
>>  - Merge
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6
>
> src/java.base/share/classes/java/lang/Thread.java line 742:
> 
>> 740:      * @param name thread name, can be null
>> 741:      * @param characteristics thread characteristics
>> 742:      * @param bound true when bound to an OS thread
> 
> Nit: s/OS/VM/ ?

I think it would be confusing to use "VM" here. The intention is that "true" means the virtual thread will be bound to an OS thread once it has started. Yes, technically it's whatever the VM implements but I think that is too much to try to explain in the parameter description.

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From kbarrett at openjdk.java.net  Thu Jun  2 07:49:05 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 2 Jun 2022 07:49:05 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for portability
Message-ID: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>

Please review this new mechanism for "poisoning" uses of certain functions,
along with marking specific uses as still being permitted.  One use for this
is to discourage use of external library functions for which HotSpot provides
extended versions or portability shims.  Another is to prevent uses of certain
functions considered "insecure", promoting alternatives or requiring strong
scrutiny.

The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
implementations.  Comments in the code describe the details.  For some
compilers we didn't find any features that would permit such poisoning.  As a
result, only shared code has complete coverage.

For gcc and clang we use an attribute that warns about references to an
annotated function, and scoped suppression of that warning.  This
functionality is provided since gcc9 and clang14.  (I haven't tested with
clang; version 14 is more recent than I have access for.  But the docs
describe an explicit match to the gcc functionality.)

For Visual Studio I was unable to find a workable poisoning mechanism.  Using
deprecation annotations and scoped suppression of the consequent warnings
seemed plausible, but ran into problems.  (See comments in code for details.)
But we provide scoped suppression of deprecation warnings anyway.  Many of the
functions we'd poison are already conditionally deprecated under the control
of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
we've removed or annotated all calls associated with one of those macros we
can remove the macro from our builds, preventing new uses from creeping into
unshared code.

The aix-ppc port doesn't provide poisoning support.  The version of clang used
by xlclang is older than the warning attribute and suppression.

Along with the new mechanisms, a few functions are poisoned by this change.
More functions can be added as folks have time to address their uses.

The poisoning declarations are in globalDefinitions.hpp, since the signatures
may use types that have platform-specific definitions or locations that are
provided within that header.  That header is included (directly or indirectly)
nearly everywhere, so provides good coverage.

The rest of the changes are to address existing uses of the newly forbidden
functions, either using something else or annotating them as permitted uses.

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

Commit messages:
 - forbid direct calls to ::exit and ::_exit
 - forbid some functions
 - define macros

Changes: https://git.openjdk.java.net/jdk/pull/8982/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8982&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8214976
  Stats: 153 lines in 11 files changed: 127 ins; 1 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8982/head:pull/8982

PR: https://git.openjdk.java.net/jdk/pull/8982

From aph at openjdk.java.net  Thu Jun  2 08:28:31 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 2 Jun 2022 08:28:31 GMT
Subject: RFR: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <ho5tr8ENbiIHydK8mxWUx7s-0cYPwmjCAVkT_l0tz3w=.fa1a2b4f-567d-4f1e-8452-fda4da670f96@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
 <nbQ7utLIRvqGnQYtOISIVni8kj0R4iDCNL1lgUnghcw=.467aa293-e45e-49c3-8630-f2f1aa454d69@github.com>
 <1e0OZS7yYpNKvq9V91bF4jwtlpufPMj3dLVwhl8GUDs=.704bdbba-ea60-47f6-859e-62b05dded898@github.com>
 <YaBh9QAk7bjqKGFKhQQWGd258xw95rneGO1a26yEKek=.ab732e02-3e3d-4a67-b208-5aef732cefdf@github.com>
 <ho5tr8ENbiIHydK8mxWUx7s-0cYPwmjCAVkT_l0tz3w=.fa1a2b4f-567d-4f1e-8452-fda4da670f96@github.com>
Message-ID: <dOsm7loUUkBvoVmEcTP986YHBRsXdWs5FA_sqvFOBhs=.68219e79-5a2a-4239-b2c7-879d5472ac19@github.com>

On Wed, 1 Jun 2022 20:29:21 GMT, Dean Long <dlong at openjdk.org> wrote:

> > @dean-long , are you happy with that explanation?
> 
> Yes, and thanks for the interesting performance data.

It probably makes no difference, to be honest. I'm just a bit more confident right now to match an instruction that I am 100% certain never gets emitted by the compiler.

> I had an ulterior motive for my question. I was hoping there would be a platform-independent pattern that new ports could use initially, then optimize later. I think the
> 
> ```
>  b done
>  (raw data)
>  done:
> ```
> 
> pattern will work as long as call sites without a post-call NOP disambiguate by using a regular NOP. Then NativePostCallNop::check() will only see either a NOP or a branch.

True, although you'd have to find them all.

We could perhaps argue that  JMP *+ 2 (or however the offset works out) will never be emitted by a compiler, and I think it won't be with current C1 and C2, but it feels rather icky to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From alanb at openjdk.java.net  Thu Jun  2 09:07:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 09:07:32 GMT
Subject: Integrated: 8287496: Alternative virtual thread implementation that
 maps to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <yAA7004X8JTNUfpUTjv1JBp1c8kEgq3PdtdS_GQVtGI=.8606e198-0560-4119-a3c7-82dfb300b0ef@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

This pull request has now been integrated.

Changeset: 6ff2d89e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ff2d89ea11934bb13c8a419e7bad4fd40f76759
Stats:     747 lines in 72 files changed: 574 ins; 53 del; 120 mod

8287496: Alternative virtual thread implementation that maps to OS thread

Reviewed-by: rehn, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From shade at openjdk.java.net  Thu Jun  2 09:58:37 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Jun 2022 09:58:37 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v3]
In-Reply-To: <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <WmKWHvGRGDlxNeY2uaLtVPvCQwPq4PZ65WzvEM9sM1A=.46a22794-95ba-48d6-9017-c8cb11d5ab4a@github.com>
Message-ID: <i5qtOVrZjpamRDsl8LE_YxezyL2v9JWHatlHjh1dISE=.0d920135-ce1b-492c-b031-c8c20881d2d0@github.com>

On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fixed another typo in comment
>  - Merge
>  - Fix typos in comments
>  - Allowing linking without intrinsic stub, contributed-by: rehn
>  - Continuation clinit should fail if no continuations support
>  - Fix merge issue with test
>  - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
>  - Update
>  - Expend test coverage
>  - Merge
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6

> A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

See #8990.

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

PR: https://git.openjdk.java.net/jdk/pull/8939

From chagedorn at openjdk.java.net  Thu Jun  2 11:33:43 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 2 Jun 2022 11:33:43 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v10]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <AeVBsr1kvyVMgW2YX9iF_ku0oYzBKe5JfIoXQXK1Fpg=.6ee96ffb-d27f-4d38-a6e6-c309f4048271@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:

 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - Apply remaining review comments from Thomas Stuefe
 - Change load_dwarf_file with DwarfFilePath and DebugInfo
 - Revert renaming on Windows
 - ... and 55 more: https://git.openjdk.java.net/jdk/compare/6e55a72f...8c2c4ab4

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

Changes: https://git.openjdk.java.net/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=09
  Stats: 2784 lines in 18 files changed: 2687 ins; 41 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126

PR: https://git.openjdk.java.net/jdk/pull/7126

From chagedorn at openjdk.java.net  Thu Jun  2 11:33:44 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 2 Jun 2022 11:33:44 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v9]
In-Reply-To: <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <qzR7-THzprQvPm2icCX-LHOb68Y7M_r7HOMaDCuTWFo=.f452c2fd-9787-48ee-9823-4a10dbc66257@github.com>
 <yMt7s6pHlciJmkO9lVt6p2KCRLiU_4tP2MBwtGcBDUc=.fe56c895-a352-4318-a6e4-3f32a4da7ae6@github.com>
 <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
Message-ID: <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>

On Wed, 25 May 2022 09:05:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thanks Thomas for doing the testing!
>
>> Thanks Thomas for doing the testing!
> 
> Hi Christian,
> 
> I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom.
> 
> I see test errors in TestDwarf on ppcle and x64, however. On x64:
> 
> 
> ----------System.out:(52/5198)----------
> Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hot
 spot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ]
> [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490
> [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490
> [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490
> Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log'
> [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490
> [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/c1_Compilation.cpp:616
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505
> #  assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned
> #
> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x73ca34]  Compilation::~Compilation()+0x84
> #
> # CreateCoredumpOnCrash turned off, no core file dumped
> #
> # An error report file with more information is saved as:
> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log
> [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo
> [1.842s][info][dwarf] Failed to parse the line number program header correctly.
> [1.842s][info][dwarf] Failed to process the line number program correctly.
> [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a
> [1.843s][info][dwarf] Failed to parse the line number program header correctly.
> [1.843s][info][dwarf] Failed to process the line number program correctly.
> [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011
> [1.845s][info][dwarf] Failed to parse the line number program header correctly.
> [1.845s][info][dwarf] Failed to process the line number program correctly.
> [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78
> [1.849s][info][dwarf] Failed to parse the line number program header correctly.
> [1.849s][info][dwarf] Failed to process the line number program correctly.
> [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3
> [1.852s][info][dwarf] Failed to parse the line number program header correctly.
> [1.852s][info][dwarf] Failed to process the line number program correctly.
> [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546
> [1.855s][info][dwarf] Failed to parse the line number program header correctly.
> [1.855s][info][dwarf] Failed to process the line number program correctly.
> [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9
> #
> # Compiler replay data is saved as:
> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> hs_err_file: hs_err_pid44490.log
> ----------System.err:(15/1242)----------
> java.lang.RuntimeException: Could not find filename or line number in "V  [libjvm.so+0x74176a]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false
> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
> 	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
> 	at TestDwarf.runAndCheck(TestDwarf.java:163)
> 	at TestDwarf.test(TestDwarf.java:99)
> 	at TestDwarf.main(TestDwarf.java:90)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:1585)

After getting some more logs from @tstuefe, it turns out that they are using GCC 8 in the testing which emits the `.debug_line` section in DWARF 2 format which we do not allow and we bail out during parsing. This lets `TestDwarf` fail. 

The `.debug_line` section is already handled differently by the parser compared to the other sections. GCC 10 emits DWARF 3 for some reason (even though it should emit DWARF 4 as for the other sections) while GCC 11 emits DWARF 4. Therefore, the parser can handle both DWARF 3 and 4 for `.debug_line`. Having a look at the DWARF 2 spec, it turns out that we can reuse the code for parsing DWARF 3. This allows us to update the version bailout of `.debug_line` to allow DWARF 2 as valid version. I've tested this change by building HotSpot with GCC 8.2 and playing around with it.

In this process, I've also changed `TestDwarf.java` to skip all its tests if there was a bailout of the parser due to an unsupported DWARF format. I've added some more error logging.

I've also decided to get rid of UL as discussed before and replaced it by `tty` logging in combination with a new `TraceDwarfLevel` develop flag (for the different log levels).

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

PR: https://git.openjdk.java.net/jdk/pull/7126

From dholmes at openjdk.java.net  Thu Jun  2 13:09:38 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Jun 2022 13:09:38 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
Message-ID: <rI_Qg3ghV_H35e1yUHtzLjKUkkluWSVCpsIo_h2IcVs=.d35b7dda-8b43-462d-93fa-f302b9bbe26c@github.com>

On Wed, 1 Jun 2022 22:02:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

Hi Kim,
This seems fine to me.
Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8982

From dholmes at openjdk.java.net  Thu Jun  2 13:23:31 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Jun 2022 13:23:31 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
Message-ID: <B6PT83nTnh6lu_Aq_11cG146Dw34nhP26bi9lphVEgc=.b460a65a-81bd-4765-b048-f36f3fdc0540@github.com>

On Wed, 1 Jun 2022 11:59:36 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous if stmt

My comments were only "drive-by" observations. You really need the compiler folk to perform the actual review here.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From rehn at openjdk.java.net  Thu Jun  2 13:55:56 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 2 Jun 2022 13:55:56 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <VqsS_Pc4nhbyjX021XeyWvZISGaRQFLzcW6X9ah4Koc=.6008c015-239d-4cdc-a8ff-404687e590a2@github.com>

On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

> Please review this PR for fixing JDK-8287281.
> 
> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
> 
> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Currently running tier1-5 to check if I'm missing something.

I agree, thanks for fixing.

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Thu Jun  2 13:55:56 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 2 Jun 2022 13:55:56 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case of
 target thread being current
Message-ID: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>

Please review this PR for fixing JDK-8287281.

I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.

Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.

Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.


Currently running tier1-5 to check if I'm missing something.

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

Commit messages:
 - Disallow handshaking with self

Changes: https://git.openjdk.java.net/jdk/pull/8992/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287281
  Stats: 8 lines in 3 files changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8992/head:pull/8992

PR: https://git.openjdk.java.net/jdk/pull/8992

From fgao at openjdk.java.net  Thu Jun  2 14:16:35 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Thu, 2 Jun 2022 14:16:35 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
Message-ID: <E77fljXlWNAa0sqoZxiF_gr_MivBCYuKYSdIAFtOrAg=.523a46c6-3d5e-4c83-aea9-9138fae33dca@github.com>

On Thu, 2 Jun 2022 04:37:58 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.
>> 
>> That may be preferable "simple fix" vs suggested changes for "short term solution".
>> 
>> The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
>> Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.
>> 
>> BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.
>
> @vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.

Hi @sviswa7 , https://github.com/openjdk/jdk/pull/7806 implemented an interface for auto-vectorization to disable some unprofitable cases on aarch64. Can it also be applied to your case?

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Thu Jun  2 15:42:13 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 15:42:13 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
Message-ID: <1KZNZmrZNxn_YDSTrosuyO7KjL2GaJEi8uiOO1ZZZCo=.7fc2d5a3-31a7-4e30-b278-5e705862c001@github.com>

On Thu, 2 Jun 2022 04:34:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change SuperWordMaxVectorSize to develop option

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

> 900:       if (_stepping < 5) {
> 901:         FLAG_SET_DEFAULT(UseAVX, 2);
> 902:       }

What is this change for?

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

> 1301:   if (FLAG_IS_DEFAULT(SuperWordMaxVectorSize)) {
> 1302:     if (FLAG_IS_DEFAULT(UseAVX) && UseAVX > 2 &&
> 1303:         is_intel_skylake() && _stepping > 5) {

Should you check `_stepping >= 5`?  Otherwise `_stepping == 5` is missing in all adjustments.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From shade at openjdk.java.net  Thu Jun  2 16:41:54 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Jun 2022 16:41:54 GMT
Subject: RFR: 8287729: Loom: Check alternative implementation on x86_32
Message-ID: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>

[JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).

Additional testing:
 - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
 - [x] Linux x86_32 fastdebug, `tier2` (clean)
 - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

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

Commit messages:
 - Merge branch 'master' into JDK-8287729-loom-alt-x86-32
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8994

From alanb at openjdk.java.net  Thu Jun  2 16:41:55 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 16:41:55 GMT
Subject: RFR: 8287729: Loom: Check alternative implementation on x86_32
In-Reply-To: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
References: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
Message-ID: <QxUkLAE5mTyIiBaoeIuogfez0OFrDJdyhvf1_ApN2GY=.7950001a-e678-4358-97a3-f03f46887c99@github.com>

On Thu, 2 Jun 2022 14:35:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
>  - [x] Linux x86_32 fastdebug, `tier2` (clean)
>  - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8994

From kvn at openjdk.java.net  Thu Jun  2 17:04:24 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 17:04:24 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
Message-ID: <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>

On Thu, 2 Jun 2022 04:37:58 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I think we missed the test with setting `MaxVectorSize` to 32 (vs 64) on Cascade Lake CPU. We should do that.
>> 
>> That may be preferable "simple fix" vs suggested changes for "short term solution".
>> 
>> The objection was that user may still want to use wide 64 bytes vectors for Vector API. But I agree with Jatin argument about that.
>> Limiting `MaxVectorSize` **will** affect our intrinsics/stubs code and may affect performance. That is why we need to test it. I will ask Eric.
>> 
>> BTW, `SuperWordMaxVectorSize` should be diagnostic or experimental since it is temporary solution.
>
> @vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.

> Hi @sviswa7 , #7806 implemented an interface for auto-vectorization to disable some unprofitable cases on aarch64. Can it also be applied to your case?

Maybe. But it would require more careful changes. And that changeset is not integrated yet.
Current changes are clean and serve their purpose good.

And, as Jatin and Sandhya said, we may do proper fix after JDK 19 fork. Then we can look on your proposal.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Thu Jun  2 17:32:28 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 17:32:28 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v3]
In-Reply-To: <1KZNZmrZNxn_YDSTrosuyO7KjL2GaJEi8uiOO1ZZZCo=.7fc2d5a3-31a7-4e30-b278-5e705862c001@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Xn4njISNuNahJH7A18dqupYlaNyQ-XV0DrxWOYq_6uM=.07968d9e-f0c1-41be-89dd-54fe92a974cf@github.com>
 <1KZNZmrZNxn_YDSTrosuyO7KjL2GaJEi8uiOO1ZZZCo=.7fc2d5a3-31a7-4e30-b278-5e705862c001@github.com>
Message-ID: <mPFrpw4MP23Rih0_mGMypA2a3WV00oxkAMlfUdno3hI=.cfbe12d9-689c-426b-82b2-bec03a838526@github.com>

On Thu, 2 Jun 2022 15:37:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change SuperWordMaxVectorSize to develop option
>
> src/hotspot/cpu/x86/vm_version_x86.cpp line 902:
> 
>> 900:       if (_stepping < 5) {
>> 901:         FLAG_SET_DEFAULT(UseAVX, 2);
>> 902:       }
> 
> What is this change for?

I had some changes in this area before. This is an artifact of that. I will set it back to exactly as it was.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From aph at openjdk.java.net  Thu Jun  2 17:35:31 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 2 Jun 2022 17:35:31 GMT
Subject: Integrated: 8287567: AArch64: Implement post-call NOPs
In-Reply-To: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
References: <z9mkSQ9j387PzWQZ4N_c1HfThfOK9vxpqB-ngcwhRYw=.7a5bffdc-1709-4648-88f7-36044fc3e034@github.com>
Message-ID: <AME0TMqhA87eXJfo9pPRsAiyo87WpgHEf-eR5OpuRHw=.8cb5e727-97db-41c4-955e-d5d99c37b57e@github.com>

On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. 
> 
> I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed.

This pull request has now been integrated.

Changeset: 49e24f0c
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49e24f0cd833b77006540e871aa7d427628c058f
Stats:     46 lines in 5 files changed: 42 ins; 0 del; 4 mod

8287567: AArch64: Implement post-call NOPs

Reviewed-by: adinn, rbackman, dlong

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

PR: https://git.openjdk.java.net/jdk/pull/8955

From iklam at openjdk.java.net  Thu Jun  2 17:42:40 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Jun 2022 17:42:40 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v5]
In-Reply-To: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
Message-ID: <Jzr871RqzIxwcoojlTQLE_tYqPf2G9_NBpA8NsG07jg=.358a2032-babd-45a4-9d70-bf844a3df7c3@github.com>

> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable
> 
> - `template<typename F> void ResourceHashtable::iterate(F f)`
> - `template<typename F> void ResourceHashtable::iterate_all(F f)`
> 
> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality.
> 
> Testing with tiers 1-4.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - removed empty first line
 - Renamed DumpTimeSharedClassTable::iterate_all_live_classes() to avoid confusion with overloading

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8761/files
  - new: https://git.openjdk.java.net/jdk/pull/8761/files/8c53c418..083fb72d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=03-04

  Stats: 48 lines in 4 files changed: 5 ins; 22 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8761.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761

PR: https://git.openjdk.java.net/jdk/pull/8761

From iklam at openjdk.java.net  Thu Jun  2 17:47:38 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Jun 2022 17:47:38 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <lGZzOF1bG3ul7RWmdA9fiIP8NVgmC1hc9G5xYBnbC3c=.3507175c-352d-4bdb-ac41-07de9fd19957@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>
 <lGZzOF1bG3ul7RWmdA9fiIP8NVgmC1hc9G5xYBnbC3c=.3507175c-352d-4bdb-ac41-07de9fd19957@github.com>
Message-ID: <auAHj5F0kd6IcHCIDJW_gRt_FNVo22ctKKHh84BD0p8=.f0121263-80c6-450c-8560-9b300b0c83a5@github.com>

On Wed, 1 Jun 2022 20:08:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/cds/dumpTimeClassInfo.hpp line 209:
>> 
>>> 207:     } else {
>>> 208:       return _unregistered_count;
>>> 209:     }
>> 
>> This file has a blank first line, can you fix this?
>
> And no new line between these here:
> #define SHARED_CDS_DUMPTIMESHAREDCLASSINFO_HPP
> #include "cds/archiveBuilder.hpp"

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From iklam at openjdk.java.net  Thu Jun  2 17:47:41 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Jun 2022 17:47:41 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <m095ReJ8mhjRIV7FydlJgmCMLQCePskm6cgKOmmhT1M=.fbd6a6e1-9dca-4c0d-9d65-947da6a3e354@github.com>
Message-ID: <6nucEmzC8xL-JJUccCB-ZWil86C5h9hFJaR7naoe6Zw=.da50e51a-2342-47f2-9b0c-495438dae27a@github.com>

On Wed, 1 Jun 2022 20:17:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some clean up suggested by @stefank
>
> src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp line 76:
> 
>> 74:     return iter->do_entry(k, v);
>> 75:   };
>> 76:   iterate(function);
> 
> I don't understand this wrapper level.  Why doesn't this call into the resourceHashtable::iterate function directly?  Same with the iterate_all function?

I renamed the functions to `DumpTimeSharedClassTable::iterate_all_live_classes()` to disambiguate them from the `ResourceHashtable::iterate/_all` functions.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 665:
> 
>> 663:     ResourceMark rm;
>> 664:     UnregisteredClassesDuplicationChecker dup_checker;
>> 665:     _dumptime_table->iterate(&dup_checker);
> 
> Which iterate function does this call?

I changed it to `_dumptime_table->iterate_all_live_classes()`

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From sviswanathan at openjdk.java.net  Thu Jun  2 17:49:04 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 17:49:04 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v4]
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

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

  Review comment resolution

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8877/files
  - new: https://git.openjdk.java.net/jdk/pull/8877/files/e8ea837a..42085160

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8877&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8877.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8877/head:pull/8877

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Thu Jun  2 17:49:04 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 17:49:04 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
 <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>
Message-ID: <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>

On Thu, 2 Jun 2022 17:01:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov I have made SuperWordMaxVectorSize as a develop option as you suggested. As far as I know, the only intrinsics/stubs that uses MaxVectorSize are for clear/copy. This is done in conjunction with AVX3Threshold so we are ok there for Cascade Lake.
>
>> Hi @sviswa7 , #7806 implemented an interface for auto-vectorization to disable some unprofitable cases on aarch64. Can it also be applied to your case?
> 
> Maybe. But it would require more careful changes. And that changeset is not integrated yet.
> Current changes are clean and serve their purpose good.
> 
> And, as Jatin and Sandhya said, we may do proper fix after JDK 19 fork. Then we can look on your proposal.

@vnkozlov @jatin-bhateja Your review comments are implemented. Please take a look.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Thu Jun  2 18:03:38 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 2 Jun 2022 18:03:38 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v4]
In-Reply-To: <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
Message-ID: <QKPCVROcM5TnfFZNrAwFrXgLHpdXACx1xAUw3lyLIpg=.06870521-2e98-4f84-a7ad-84a1670a4777@github.com>

On Thu, 2 Jun 2022 17:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Looks good.
Please wait until regression and performance testing are finished. I will let you know results.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8877

From shade at openjdk.java.net  Thu Jun  2 18:18:43 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Jun 2022 18:18:43 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>
Message-ID: <ilMz6BFaIN9i4hbwtLgSYhtgft1TCwYcqa4NfQ4AKfM=.4fee41e3-63fb-490e-9e94-5b194f9846af@github.com>

On Wed, 1 Jun 2022 15:56:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
>> 
>> Sample output generated by gtest:
>> 
>> 
>> [0.292s][info][test] Bitmap (0 bits):
>> [0.292s][info][test] Bitmap (128 bits):
>> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]    64: S....... ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test] Bitmap (1024 bits):
>> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]    64: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   128: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   192: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   256: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   320: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   384: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   448: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   512: S....... ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   576: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   640: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   704: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   768: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   832: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   896: ........ ........ ........ ........ ........ ........ ........ ........
>> [0.292s][info][test]   960: ........ ........ ........ ........ ........ ........ ........ ........
>> 
>> 
>> It becomes clearer that bits 64 and 512 are set, respectively.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, new gtest
>>  - [x] Linux x86_64 release, new gtest
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8287661-bitmaps-improv
>  - Review comments
>  - Fix

Any other opinions? I'll integrate it otherwise.

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From jbhateja at openjdk.java.net  Thu Jun  2 19:02:33 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 2 Jun 2022 19:02:33 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v4]
In-Reply-To: <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
Message-ID: <jJexVeKSycHxiUvgCi4rAkmb_ErmDmdGUGdHwhORI7Y=.306cbe0a-7e2b-49a8-87a6-f85fb0aeacab@github.com>

On Thu, 2 Jun 2022 17:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Marked as reviewed by jbhateja (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From jbhateja at openjdk.java.net  Thu Jun  2 19:02:35 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 2 Jun 2022 19:02:35 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
 <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>
 <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>
Message-ID: <fdo6QofOJbEcKybe84gZ1srch77G2P8S30acxeqAdZI=.ff7a7923-aeb8-45ad-a388-771560c0790d@github.com>

On Thu, 2 Jun 2022 17:44:54 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>>> Hi @sviswa7 , #7806 implemented an interface for auto-vectorization to disable some unprofitable cases on aarch64. Can it also be applied to your case?
>> 
>> Maybe. But it would require more careful changes. And that changeset is not integrated yet.
>> Current changes are clean and serve their purpose good.
>> 
>> And, as Jatin and Sandhya said, we may do proper fix after JDK 19 fork. Then we can look on your proposal.
>
> @vnkozlov @jatin-bhateja Your review comments are implemented. Please take a look.

Thanks @sviswa7 , changes looks good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Thu Jun  2 22:32:41 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 22:32:41 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <Ln4gn237B93d4NmnHb8RXCcSIacUqYpLu6eMwJKFcLM=.4eaf44a7-c2a4-4d0e-84fd-d988d2b5904f@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'jdk:master' into JDK-8283667
>  - Use integer constant for offsetInRange all the way through
>  - Rename "use_predicate" to "needs_predicate"
>  - Rename the "usePred" to "offsetInRange"
>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

Marked as reviewed by sviswanathan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sviswanathan at openjdk.java.net  Thu Jun  2 22:32:42 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 2 Jun 2022 22:32:42 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
 <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
Message-ID: <Z9-GLbZIT7wzq73_ua6b_JlddNTNYwwsQNnHxTPPULY=.79d8dfd4-834b-4a2f-9d8c-098f3854c9de@github.com>

On Thu, 2 Jun 2022 03:24:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
>
>> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
> 
> Resolved the conflicts. Thanks!

@XiaohongGong You need one more review approval.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From coleenp at openjdk.java.net  Fri Jun  3 00:50:21 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 3 Jun 2022 00:50:21 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v5]
In-Reply-To: <Jzr871RqzIxwcoojlTQLE_tYqPf2G9_NBpA8NsG07jg=.358a2032-babd-45a4-9d70-bf844a3df7c3@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <Jzr871RqzIxwcoojlTQLE_tYqPf2G9_NBpA8NsG07jg=.358a2032-babd-45a4-9d70-bf844a3df7c3@github.com>
Message-ID: <2AV4Q08W7Pp2eQUhWwJ4eggdXP2USlrgpK6mm4Ov01c=.83575d81-8ce2-436b-8766-fde1f79ca7d8@github.com>

On Thu, 2 Jun 2022 17:42:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable
>> 
>> - `template<typename F> void ResourceHashtable::iterate(F f)`
>> - `template<typename F> void ResourceHashtable::iterate_all(F f)`
>> 
>> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality.
>> 
>> Testing with tiers 1-4.
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - removed empty first line
>  - Renamed DumpTimeSharedClassTable::iterate_all_live_classes() to avoid confusion with overloading

Looks good.  Thanks for the help and discussion offline. Now it makes sense.

src/hotspot/share/cds/dumpTimeClassInfo.hpp line 221:

> 219:   template<class ITER> void iterate(ITER* iter) const;
> 220:   template<typename Function> void iterate(Function function) const;
> 221:   template<typename Function> void iterate_all(Function function) const;

This helps a lot and thanks for the comment, which describes why there's a wrapper for this class.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8761

From kvn at openjdk.java.net  Fri Jun  3 02:49:34 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 3 Jun 2022 02:49:34 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v4]
In-Reply-To: <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
Message-ID: <dUQGY3rQZGCu6c__JNWH7aMD8FyIIM2zZREstqLki0Y=.dec8a5b5-5b44-4cf1-9e51-e3fe8c28931e@github.com>

On Thu, 2 Jun 2022 17:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

Regression testing results are good. Waiting performance results.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From iklam at openjdk.java.net  Fri Jun  3 04:00:23 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Jun 2022 04:00:23 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v6]
In-Reply-To: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
Message-ID: <ucPuKpw_oZzZ1coyAH8AMITeIp8Tq1kcx_z5T1rGqCY=.5b29fcb3-31eb-41ff-aac8-9de76d4716b7@github.com>

> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable
> 
> - `template<typename F> void ResourceHashtable::iterate(F f)`
> - `template<typename F> void ResourceHashtable::iterate_all(F f)`
> 
> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality.
> 
> Testing with tiers 1-4.

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

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8276789-cpp-lambda-for-resourceHash-iterate
 - removed empty first line
 - Renamed DumpTimeSharedClassTable::iterate_all_live_classes() to avoid confusion with overloading
 - some clean up suggested by @stefank
 - Fixed typo in comment (it loader -> its loader)
 - Better naming of variables. E.g., (F f) -> (Function function), as suggested by @@stefank
 - changed to use lambda capture by reference [&]
 - 8276789: Support C++ lambda in ResourceHashtable::iterate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8761/files
  - new: https://git.openjdk.java.net/jdk/pull/8761/files/083fb72d..811beca9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=04-05

  Stats: 106908 lines in 1574 files changed: 43508 ins; 53400 del; 10000 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8761.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761

PR: https://git.openjdk.java.net/jdk/pull/8761

From iklam at openjdk.java.net  Fri Jun  3 06:02:39 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Jun 2022 06:02:39 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <ncGeBA4eoJVWDXWEyIA4wn7CjsYz2IMGDnQJZrdWAvA=.0ee36129-afa5-4d4a-bb6e-ff490607c2f9@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <ncGeBA4eoJVWDXWEyIA4wn7CjsYz2IMGDnQJZrdWAvA=.0ee36129-afa5-4d4a-bb6e-ff490607c2f9@github.com>
Message-ID: <cfQhMF9O38oMaYyxwKUsA_2FxY7K-IUNxpXTJA1LqCo=.0892a766-55e1-40e2-8bf0-53778db72447@github.com>

On Wed, 25 May 2022 06:28:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   some clean up suggested by @stefank
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank and @coleenp for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From iklam at openjdk.java.net  Fri Jun  3 06:02:41 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Jun 2022 06:02:41 GMT
Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate
 [v4]
In-Reply-To: <8cR-neKResMLcTtZE3_6rreY-m60SD4R_C9BX4zVhbA=.fb14951f-a749-4bfc-8ba6-0f63aac7199a@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
 <ANnu8lzxTYyTlOnnPwjuPuZNI3MuY5SeBa6gkgWw3rg=.55877cc4-a86c-47ef-94e1-852d891a8c1b@github.com>
 <OjV4X6TYDwZ9lMkA6wi0gSiBPtPJKlu_B4zeTbzIFdo=.e27c0b9a-22a0-4a6b-a73f-de0df794227c@github.com>
 <nR35jxHow0rqnRxJXUWLee22utffmhA-QoE_t3CyOCQ=.772398b7-6833-4ca0-a94a-18272d7e04b4@github.com>
 <m3DR3mzjZ9LB0kvBXGefk7yJ0TP1xdfhXFEm2qTrYaI=.4721e8c0-a550-4dbd-8473-b4f5d8e06d01@github.com>
 <dEw_BNTJajQ69GlNySwGWyrd0MtM7SpUHuuhsNi3o4g=.7be3680f-9e4a-40df-a9b5-d7203e505f94@github.com>
 <8cR-neKResMLcTtZE3_6rreY-m60SD4R_C9BX4zVhbA=.fb14951f-a749-4bfc-8ba6-0f63aac7199a@github.com>
Message-ID: <iLo0UUNlpEBWNCtb_0myBj3sTh6Y6TbhF-NTfwrwrR8=.11914823-fa7d-446a-b936-1c0c4a91b070@github.com>

On Thu, 2 Jun 2022 05:10:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> [Not a review, just a drive-by comment]
>> SFINAE operates on arguments and signatures; it doesn't reach into the bodies
>> of (potential) callees like that. The disambiguation is happening because one
>> argument (the Closure object) is passed as a pointer, while the other is a
>> lambda object (not a pointer). In the pointer to closure object case the ITER*
>> overload is a better match, so is selected. In the lambda case, it's not a
>> pointer so only the non-pointer overload is applicable.
>
> (And SFINAE _can't_ reach into the body like that, since the body might not be available.)

@kimbarrett Thanks for the explanation. So we're lucky because we use `ITER*` in the old API. If it were `ITER&` then the C++ compiler would complain about ambiguous overloading.

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From iklam at openjdk.java.net  Fri Jun  3 06:02:43 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Jun 2022 06:02:43 GMT
Subject: Integrated: 8276789: Support C++ lambda in ResourceHashtable::iterate
In-Reply-To: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
References: <uaZzRmTFIAftfET6zlmu-iJaMdzyprGRVNWM8pMJU1c=.1875894a-84b3-46b2-a62b-7e3cac94206a@github.com>
Message-ID: <EzvOZOmqGdE_xnK5kurM7h4uwAkoMFOe6mKDc0zrawk=.f35cebf2-47be-4ff3-a96c-70f06d23f0f9@github.com>

On Tue, 17 May 2022 23:37:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable
> 
> - `template<typename F> void ResourceHashtable::iterate(F f)`
> - `template<typename F> void ResourceHashtable::iterate_all(F f)`
> 
> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality.
> 
> Testing with tiers 1-4.

This pull request has now been integrated.

Changeset: b544b8b7
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b544b8b7d43907e93263db31ba3cc6d5951bcaee
Stats:     119 lines in 5 files changed: 36 ins; 45 del; 38 mod

8276789: Support C++ lambda in ResourceHashtable::iterate

Reviewed-by: stefank, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/8761

From shade at openjdk.java.net  Fri Jun  3 06:36:22 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 06:36:22 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
Message-ID: <jzyz4NZ20h5ZAiKOEDS7Zy1Bs6-c4AptSyDz6NfZo9U=.1be6dd67-098d-4843-9604-3a84b60f3951@github.com>

On Wed, 1 Jun 2022 15:09:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Harmonize exception handler invocation
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Revert test groups
>  - Fix

Still open for reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From shade at openjdk.java.net  Fri Jun  3 07:27:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 07:27:32 GMT
Subject: Integrated: 8287661: Fix and improve BitMap::print_on(outputStream*)
In-Reply-To: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
Message-ID: <0yLmW5UupVbOsFFh83RnRL3YGoWmLDFTpH2IGHcWbCY=.d3247974-fdf4-4913-8693-6b9772781e1d@github.com>

On Wed, 1 Jun 2022 10:04:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found these inconvenient during debugging using the `BitMap::print_on`. We pass the `outputStream*` to the method, but do not use it. Also, the output is hard to read for large bitmaps. 
> 
> Sample output generated by gtest:
> 
> 
> [0.292s][info][test] Bitmap (0 bits):
> [0.292s][info][test] Bitmap (128 bits):
> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]    64: S....... ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test] Bitmap (1024 bits):
> [0.292s][info][test]     0: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]    64: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   128: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   192: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   256: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   320: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   384: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   448: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   512: S....... ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   576: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   640: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   704: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   768: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   832: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   896: ........ ........ ........ ........ ........ ........ ........ ........
> [0.292s][info][test]   960: ........ ........ ........ ........ ........ ........ ........ ........
> 
> 
> It becomes clearer that bits 64 and 512 are set, respectively.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, new gtest
>  - [x] Linux x86_64 release, new gtest

This pull request has now been integrated.

Changeset: 625821da
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/625821dae7589b510de00ffd506a592ddb606318
Stats:     36 lines in 2 files changed: 33 ins; 0 del; 3 mod

8287661: Fix and improve BitMap::print_on(outputStream*)

Reviewed-by: stefank

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From duke at openjdk.java.net  Fri Jun  3 07:38:28 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 3 Jun 2022 07:38:28 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v2]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <EbWRmYnMzjukk2NCHJmEs_EWjJgwZbyurlrfJY8Ej2c=.29e101ea-855b-440b-8d21-ec3f17181c50@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
> 
> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Currently running tier1-5 to check if I'm missing something.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Call do_thread if handshaking with current thread as target

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8992/files
  - new: https://git.openjdk.java.net/jdk/pull/8992/files/14bee58c..b7b4c086

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=00-01

  Stats: 9 lines in 3 files changed: 2 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8992/head:pull/8992

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Fri Jun  3 07:39:22 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 3 Jun 2022 07:39:22 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <e8aqXbONVx4Lz433D4Q9v3ccGtfr37Jl3QsTNhkuToc=.e32206a3-1f20-4c9a-a562-065dc148fec4@github.com>

On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

> Please review this PR for fixing JDK-8287281.
> 
> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
> 
> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Currently running tier1-5 to check if I'm missing something.

The tests failed and my assumption was wrong: There are other instances of handshaking with their own thread as target, We reverse the strategy and call `do_thread` directly in `Handshake::execute`.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Fri Jun  3 07:46:42 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 3 Jun 2022 07:46:42 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v3]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <PQ1Q6z4clPGaLkgZyhg7UbhtDJQl3xHPRNqyCadDeys=.4dbf8795-f17c-4dba-a283-03e9e7487692@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
> 
> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Currently running tier1-5 to check if I'm missing something.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Use is_handshake_safe_for and add the return

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8992/files
  - new: https://git.openjdk.java.net/jdk/pull/8992/files/b7b4c086..b40577f0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From rrich at openjdk.java.net  Fri Jun  3 07:57:22 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 3 Jun 2022 07:57:22 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
Message-ID: <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>

> This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()`
> 
> Testing:
> 
> jtreg:test/hotspot/jtreg:hotspot_loom
> jtreg:test/jdk:jdk_loom
> 
> On linux x86_64 and aarch64.
> 
> On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout.

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

 - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
 - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
 - Remove dead code from generate_cont_thaw

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8863/files
  - new: https://git.openjdk.java.net/jdk/pull/8863/files/9489400f..c82674a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8863&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8863&range=00-01

  Stats: 81814 lines in 880 files changed: 30489 ins; 44462 del; 6863 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8863/head:pull/8863

PR: https://git.openjdk.java.net/jdk/pull/8863

From duke at openjdk.java.net  Fri Jun  3 09:45:31 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 3 Jun 2022 09:45:31 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
> 
> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Currently running tier1-5 to check if I'm missing something.

Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:

 - do_thread(target) not self
 - Remove checks for is_handshake_for, instead call Handshake::execute
 - Switch order of handshake check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8992/files
  - new: https://git.openjdk.java.net/jdk/pull/8992/files/b40577f0..bf75d4c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=02-03

  Stats: 15 lines in 3 files changed: 0 ins; 8 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8992/head:pull/8992

PR: https://git.openjdk.java.net/jdk/pull/8992

From rehn at openjdk.java.net  Fri Jun  3 10:43:33 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 3 Jun 2022 10:43:33 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
Message-ID: <4BQ8Crojf7_DbRlIA5zZkYA8MAj2n6k716_zwO4h0pQ=.6b5ab8da-a8ef-4377-bd06-db748d4adb6a@github.com>

On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly.  I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`.
>> 
>> Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done.
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Currently running tier1-5 to check if I'm missing something.
>
> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - do_thread(target) not self
>  - Remove checks for is_handshake_for, instead call Handshake::execute
>  - Switch order of handshake check

Thanks for the update, looks good.

Remember to re-run the tests!

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

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8992

From shade at openjdk.java.net  Fri Jun  3 11:50:22 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 11:50:22 GMT
Subject: RFR: 8287729: Loom: Check alternative implementation on x86_32
In-Reply-To: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
References: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
Message-ID: <U1pfqQd69n7IZ_g_C6nWQoJGwtVjhtv3tD4EEh-hleM=.794bc790-decd-4830-8912-d8697f2ff109@github.com>

On Thu, 2 Jun 2022 14:35:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
>  - [x] Linux x86_32 fastdebug, `tier2` (clean)
>  - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

GHA runs seem clean as well, apart from `ToolEnablePreviewTest` failure that is handled by #8995. I would like to integrate this. Any more reviewers?

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

PR: https://git.openjdk.java.net/jdk/pull/8994

From zgu at openjdk.java.net  Fri Jun  3 12:20:32 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 3 Jun 2022 12:20:32 GMT
Subject: RFR: 8287729: Loom: Check alternative implementation on x86_32
In-Reply-To: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
References: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
Message-ID: <06P5e2iyTc3-efF8ADygjG8DUyL8bT1ytyg-sc_XJ7M=.a5848fcd-04e7-49ed-b2c4-d273d67e6535@github.com>

On Thu, 2 Jun 2022 14:35:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
>  - [x] Linux x86_32 fastdebug, `tier2` (clean)
>  - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8994

From shade at openjdk.java.net  Fri Jun  3 12:20:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 12:20:32 GMT
Subject: RFR: 8287729: Loom: Check alternative implementation on x86_32
In-Reply-To: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
References: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
Message-ID: <3xO2LOu_ZFkbI_ewEvThqbLuR5tWYOuAuLODb7rQqd0=.6db41274-9562-4806-9334-4d0271273b3a@github.com>

On Thu, 2 Jun 2022 14:35:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
>  - [x] Linux x86_32 fastdebug, `tier2` (clean)
>  - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/8994

From shade at openjdk.java.net  Fri Jun  3 12:22:04 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 12:22:04 GMT
Subject: Integrated: 8287729: Loom: Check alternative implementation on x86_32
In-Reply-To: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
References: <YZ0eFE1JEiHuAjEhVYwzDGOJKnOGUVbEgVLu4tVy6Bw=.74e0522a-ef5c-4882-b6aa-7ec42d19addb@github.com>
Message-ID: <GUgoKxbUkvuHI4DqJsrXoyC0fhNmA_PqZOmdTcW76J8=.8f353a8f-2cee-4432-995c-d0b3ea663f6f@github.com>

On Thu, 2 Jun 2022 14:35:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought in alternative implementation for ports to use. This change tests that x86_32 works well with it, and removes the relevant exclusion lists. JVMTI parts are handled by [JDK-8287726](https://bugs.openjdk.java.net/browse/JDK-8287726).
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug, `tier1` (one failure, pre-existing)
>  - [x] Linux x86_32 fastdebug, `tier2` (clean)
>  - [x] Linux x86_32 fastdebug, `tier3` (a few interesting failures, look pre-existing, beyond the scope of this PR)

This pull request has now been integrated.

Changeset: 33b9d770
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/33b9d77065e65d3ba86b4d8250b1abe5743f0cef
Stats:     68 lines in 2 files changed: 0 ins; 68 del; 0 mod

8287729: Loom: Check alternative implementation on x86_32

Reviewed-by: alanb, zgu

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

PR: https://git.openjdk.java.net/jdk/pull/8994

From pchilanomate at openjdk.java.net  Fri Jun  3 15:19:32 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 3 Jun 2022 15:19:32 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
Message-ID: <WcB8_IM9jOFcsIiu8_QgIE_SEQGsR5RyRMUbyO_gSIs=.f815229b-0cc1-4aac-96cf-f2754e616a2d@github.com>

On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - do_thread(target) not self
>  - Remove checks for is_handshake_for, instead call Handshake::execute
>  - Switch order of handshake check

Looks good to me.

Thanks,
Patricio

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

Marked as reviewed by pchilanomate (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8992

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>

This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).

I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).

`MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

Commit messages:
 - Add null check on Buffer::checkState
 - Add docs
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - Add @ForceInline in hot path from var handle access
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d5b6c7bd...68028fa4

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287809
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <AgqwxT-Tw5SRrC3fkr33yz5v709cCPjTuPTDYsdxpfQ=.68b76852-db8f-4aea-a185-abf8f460ece7@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Note: other cleanups are possible - such as flattening `ResourceList` into `MemorySession.State`. While that is possible, that's a tricky step, given that the session state can be registered against a cleaner. One option, which I explored, would be to use `MemorySessionImpl` for reachability - which then has an impact on `ScopedMemoryAccess`, as we would have to add reachability fences on the session, as well as on the session state. In any case, I'd like to proceed by steps, since this cleanup was already getting big enough.

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

PR: https://git.openjdk.java.net/jdk/pull/9017

From kvn at openjdk.java.net  Fri Jun  3 16:02:38 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 3 Jun 2022 16:02:38 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
Message-ID: <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>

On Fri, 3 Jun 2022 07:57:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()`
>> 
>> Testing:
>> 
>> jtreg:test/hotspot/jtreg:hotspot_loom
>> jtreg:test/jdk:jdk_loom
>> 
>> On linux x86_64 and aarch64.
>> 
>> On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
>  - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
>  - Remove dead code from generate_cont_thaw

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8863

From jvernee at openjdk.java.net  Fri Jun  3 18:56:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 18:56:53 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>

On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8263377: Store method handle linkers in the 'non-nmethods' heap

Some initial comments. The codeBlob code looks mostly good to me. But, I don't have enough knowledge about the GC and IC changes to be able to say the same about that.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1168:

> 1166:   int frame_complete = ((intptr_t)__ pc()) - start;  // not complete, period
> 1167:   __ flush();
> 1168:   int stack_slots = SharedRuntime::out_preserve_stack_slots();  // no out slots at all, actually

`iid`, `start`, `frame_complete` and `stack_slots` variables are no longer used now it seems. Please remove them.
Suggestion:


  // First instruction must be a nop as it may need to be patched on deoptimisation
  __ nop();
  gen_special_dispatch(masm,
                       method,
                       in_sig_bt,
                       in_regs);
  __ flush();

src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 751:

> 749: 
> 750:   vmIntrinsics::ID iid = method->intrinsic_id();
> 751:   intptr_t start = (intptr_t)__ pc();

Suggestion:

src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp line 1629:

> 1627: 
> 1628:   vmIntrinsics::ID iid = method->intrinsic_id();
> 1629:   intptr_t start = (intptr_t)__ pc();

unused variables
Suggestion:

src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1124:

> 1122: 
> 1123:   vmIntrinsics::ID iid = method->intrinsic_id();
> 1124:   intptr_t start = (intptr_t)__ pc();

Suggestion:

src/hotspot/cpu/s390/sharedRuntime_s390.cpp line 1303:

> 1301:   int total_in_args = method->size_of_parameters();
> 1302:   vmIntrinsics::ID iid = method->intrinsic_id();
> 1303:   intptr_t start = (intptr_t) __ pc();

Suggestion:

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1328:

> 1326: 
> 1327:   vmIntrinsics::ID iid = method->intrinsic_id();
> 1328:   intptr_t start = (intptr_t)__ pc();

Suggestion:

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1428:

> 1426: 
> 1427:   vmIntrinsics::ID iid = method->intrinsic_id();
> 1428:   intptr_t start = (intptr_t)__ pc();

Suggestion:

src/hotspot/share/ci/ciMethod.cpp line 1131:

> 1129:                      CompiledMethod* cm = (code == nullptr) ? nullptr : code->as_compiled_method_or_null();
> 1130:                      if (cm != NULL && (cm->comp_level() == CompLevel_full_optimization)) {
> 1131:                        _instructions_size = cm->insts_end() - cm->verified_entry_point();

So, the old code only used sets _instruction_size if `comp_level` is `CompLevel_full_optimization`. Since the old shared runtime code used `new_native_nmethod`, which ends up setting comp_level to `CompLevel_none`, this branch is also not being taken in the current code?

In that case, this looks good.

src/hotspot/share/classfile/javaClasses.cpp line 2675:

> 2673:       CodeBlob* nm = method->code();
> 2674:       if (WizardMode && nm != NULL) {
> 2675:         sprintf(buf + (int)strlen(buf), "(nmethod " INTPTR_FORMAT ")", (intptr_t)nm);

Maybe change the text here as well, since this might not be an nmethod.
Suggestion:

        sprintf(buf + (int)strlen(buf), "(code " INTPTR_FORMAT ")", (intptr_t)nm);

src/hotspot/share/classfile/systemDictionary.cpp line 2049:

> 2047:   assert(spe != NULL && spe->method() != NULL, "");
> 2048:   assert(Arguments::is_interpreter_only() || (spe->method()->has_compiled_code() &&
> 2049:          spe->method()->code()->code_begin() == spe->method()->from_compiled_entry()),

Not sure if this assert is still needed/useful, since we should only encounter MH linker blobs here, for which the `from_compiled_entry` is always `code_begin`.

I'd suggest just removing this assert.

src/hotspot/share/code/codeBlob.cpp line 342:

> 340: MethodHandleIntrinsicBlob* MethodHandleIntrinsicBlob::create(const methodHandle& method,
> 341:   CodeBuffer *code_buffer) {
> 342:   code_buffer->finalize_oop_references(method);

Can you please explain why this is needed? (I'm a bit surprised since the constructor asserts that `total_oop_size` is 0)

Thanks.

src/hotspot/share/code/codeBlob.cpp line 347:

> 345:   {
> 346:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 347:     int mhi_size = CodeBlob::allocation_size(code_buffer, sizeof(MethodHandleIntrinsicBlob));

The allocation size could also be computed before taking the code cache lock. BufferBlob also does this for example, but others don't. I think it makes sense to have it outside of the mutex block though, to minimize the time we need to hold the lock. I don't see anything in there that seems to require the lock. (Maybe we should clean up other cases in a followup as well).

src/hotspot/share/code/codeBlob.cpp line 354:

> 352:   if (mhi != NULL) {
> 353:     debug_only(mhi->verify();) // might block
> 354:   }

This is debug only. Looking at CodeCache::allocate, it can only return `NULL` if the allocation size is `<= 0`, in which case an earlier assert will already fire. So, this null check doesn't seem needed?
Suggestion:

  debug_only(mhi->verify();) // might block

src/hotspot/share/code/codeBlob.cpp line 360:

> 358: void MethodHandleIntrinsicBlob::verify() {
> 359:   // Make sure all the entry points are correctly aligned for patching.
> 360:   NativeJump::check_verified_entry_alignment(code_begin(), code_begin());

This method only seems implemented on x86, which ignores the first argument. Maybe it's a good opportunity to clean up the first argument?

src/hotspot/share/code/codeBlob.cpp line 366:

> 364:   if (!CodeCache::contains((void*)this)) {
> 365:     fatal("MethodHandleIntrinsicBlob at " INTPTR_FORMAT " not in zone", p2i(this));
> 366:   }

Why would this not be true? We allocate from the code cache after all.

src/hotspot/share/compiler/compileBroker.hpp line 307:

> 305:                                  TRAPS);
> 306: 
> 307:   static CodeBlob* compile_method(const methodHandle& method,

Not so sure about these changes. It seems to me that if a method is requested to be compiled, it should always result in an nmethod.

Alternatively, would it be possible to keep these functions returning an `nmethod` but add an assert at the start to check that the passed `method` is not a method handle intrinsic?

src/hotspot/share/oops/method.cpp line 1016:

> 1014:   CodeBlob* nm = code();       // Put it into local variable to guard against concurrent updates
> 1015:   if (nm != NULL) {
> 1016:     nm->as_compiled_method()->make_not_entrant();

Looks like this code is guarding against a situation where 2 threads race to generate a native wrapper.

I think there is a potential race here with the new method handle linker blobs if 2 threads race to generate a linker, and one ends up overwriting the other as well.

I think this cast would fail, but we would also have a memory leak if we only made CompiledMethods non-entrant.

i.e. it seems there can be cases where 2 threads race to generate a MH linker, and both try to install it. We should make sure that there are no leaks in that case.

I think it might be enough to see here if `nm` is not null, and if it's a CompiledMethod, make it not entrant, and if it's an MH linker, free it directly (can delegate to `RuntimeBlob::free`). Though, I'm not sure if it's okay here to grab the code cache lock for that. Maybe there's a way to mark it as unused, and have it be cleaned up later.

src/hotspot/share/oops/method.cpp line 1304:

> 1302:     assert(blob->is_mh_intrinsic(), "must be MH intrinsic");
> 1303:     MethodHandleIntrinsicBlob* mhi = blob->as_mh_intrinsic();
> 1304:     return (mhi->method() == nullptr) || (mhi->method() == this);

The assert looks redundant, since the cast on the next line already checks it.

Also, can `mhi->method()` really be `nullptr` here?

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From jvernee at openjdk.java.net  Fri Jun  3 19:14:38 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 3 Jun 2022 19:14:38 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
Message-ID: <iE0j0InGx_3f1JBztNlzttXYN3iKIbkdGSyXJVxXiF0=.af344068-3d69-4400-81ee-f78caf1a5599@github.com>

On Fri, 3 Jun 2022 17:51:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 8263377: Store method handle linkers in the 'non-nmethods' heap
>
> src/hotspot/share/oops/method.cpp line 1016:
> 
>> 1014:   CodeBlob* nm = code();       // Put it into local variable to guard against concurrent updates
>> 1015:   if (nm != NULL) {
>> 1016:     nm->as_compiled_method()->make_not_entrant();
> 
> Looks like this code is guarding against a situation where 2 threads race to generate a native wrapper.
> 
> I think there is a potential race here with the new method handle linker blobs if 2 threads race to generate a linker, and one ends up overwriting the other as well.
> 
> I think this cast would fail, but we would also have a memory leak if we only made CompiledMethods non-entrant.
> 
> i.e. it seems there can be cases where 2 threads race to generate a MH linker, and both try to install it. We should make sure that there are no leaks in that case.
> 
> I think it might be enough to see here if `nm` is not null, and if it's a CompiledMethod, make it not entrant, and if it's an MH linker, free it directly (can delegate to `RuntimeBlob::free`). Though, I'm not sure if it's okay here to grab the code cache lock for that. Maybe there's a way to mark it as unused, and have it be cleaned up later.

Ah, actually, this code is just trying to prevent the existing native wrapper from being used in the future. Since it embeds the target native function as a constant (https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1927)

Forget what I said :) (*sigh* Friday evenings)

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From shade at openjdk.java.net  Fri Jun  3 19:23:59 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 19:23:59 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual Threads)
Message-ID: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>

Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.

Additional testing:
 - [x] Linux arm32 fastdebug build
 - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass

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

Commit messages:
 - Whitespace and comments
 - JFR barriers from Sergey
 - Cleanups
 - Flesh out generate_jfr_write_checkpoint a bit (untested)
 - Match the generator shape to x86_64
 - C2 patch from Sergey
 - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
 - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
 - ARM32 bootstraps fine without C2

Changes: https://git.openjdk.java.net/jdk/pull/8634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8634&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286360
  Stats: 201 lines in 7 files changed: 140 ins; 38 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8634/head:pull/8634

PR: https://git.openjdk.java.net/jdk/pull/8634

From dsamersoff at openjdk.java.net  Fri Jun  3 19:24:01 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Fri, 3 Jun 2022 19:24:01 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads)
In-Reply-To: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
Message-ID: <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>

On Tue, 10 May 2022 15:51:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
> 
> Additional testing:
>  - [x] Linux arm32 fastdebug build
>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass

Marked as reviewed by dsamersoff (Reviewer).

src/hotspot/cpu/arm/frame_arm.inline.hpp line 47:

> 45: }
> 46: 
> 47: inline frame::frame(intptr_t* sp) {

Will AArch64 code work?

inline frame::frame(intptr_t* sp) : frame(sp, sp, *(intptr_t**)(sp - frame::sender_sp_offset), *(address*)(sp - 1)) {}

src/hotspot/cpu/arm/stubGenerator_arm.cpp line 3106:

> 3104:       generate_phase1();
> 3105:     } else {
> 3106:       generate_all();

It might be better to check for phases explicitly:
  
     } else if (phase == 2) {
       generate_all();
     } else {
        ShouldNotReachHere();
     }

src/hotspot/share/runtime/arguments.cpp line 4208:

> 4206: #endif // COMPILER2
> 4207: 
> 4208: 

Unnecessary changes, that bring one more file to diff list. 
Please fix.

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From snazarki at openjdk.java.net  Fri Jun  3 19:24:03 2022
From: snazarki at openjdk.java.net (Sergey Nazarkin)
Date: Fri, 3 Jun 2022 19:24:03 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads)
In-Reply-To: <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
 <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>
Message-ID: <mzQgW8m668PS2jMcUMxXUswc4i-uNKT-3qOCY4YUz9o=.5ce5d120-e847-4c02-adab-c4d1144b3250@github.com>

On Fri, 3 Jun 2022 14:20:31 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

>> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
>> 
>> Additional testing:
>>  - [x] Linux arm32 fastdebug build
>>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass
>
> src/hotspot/cpu/arm/frame_arm.inline.hpp line 47:
> 
>> 45: }
>> 46: 
>> 47: inline frame::frame(intptr_t* sp) {
> 
> Will AArch64 code work?
> 
> inline frame::frame(intptr_t* sp) : frame(sp, sp, *(intptr_t**)(sp - frame::sender_sp_offset), *(address*)(sp - 1)) {}

This function seems abandoned and candidate for deletion in the  future.

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From dsamersoff at openjdk.java.net  Fri Jun  3 19:24:03 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Fri, 3 Jun 2022 19:24:03 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads)
In-Reply-To: <mzQgW8m668PS2jMcUMxXUswc4i-uNKT-3qOCY4YUz9o=.5ce5d120-e847-4c02-adab-c4d1144b3250@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
 <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>
 <mzQgW8m668PS2jMcUMxXUswc4i-uNKT-3qOCY4YUz9o=.5ce5d120-e847-4c02-adab-c4d1144b3250@github.com>
Message-ID: <uEfb2skmdvJb0BfwanNP_rPYJYA32sOQ6CL1E6P2QT0=.156774c2-2669-4d23-bb99-647bf82889b8@github.com>

On Fri, 3 Jun 2022 15:03:06 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> src/hotspot/cpu/arm/frame_arm.inline.hpp line 47:
>> 
>>> 45: }
>>> 46: 
>>> 47: inline frame::frame(intptr_t* sp) {
>> 
>> Will AArch64 code work?
>> 
>> inline frame::frame(intptr_t* sp) : frame(sp, sp, *(intptr_t**)(sp - frame::sender_sp_offset), *(address*)(sp - 1)) {}
>
> This function seems abandoned and candidate for deletion in the  future.

Nice to have comments here to avoid spending time on it in the future, but it's not crucial.

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From shade at openjdk.java.net  Fri Jun  3 19:24:04 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 19:24:04 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads)
In-Reply-To: <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
 <jlkPCjkRPS19ZlvRlpthxB7gFMBBN8wfdXCi1D1p-sk=.c7464b07-0e1f-44bd-9252-fb7c25879486@github.com>
Message-ID: <Rmf2B_duKXyuw8r1Rd1QrsvBLerQD_nTSHpRjPYp8sQ=.13baf861-abac-4549-b4cd-6fdb7f1a309e@github.com>

On Thu, 2 Jun 2022 14:15:26 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

>> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
>> 
>> Additional testing:
>>  - [x] Linux arm32 fastdebug build
>>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass
>
> src/hotspot/cpu/arm/stubGenerator_arm.cpp line 3106:
> 
>> 3104:       generate_phase1();
>> 3105:     } else {
>> 3106:       generate_all();
> 
> It might be better to check for phases explicitly:
>   
>      } else if (phase == 2) {
>        generate_all();
>      } else {
>         ShouldNotReachHere();
>      }

I agree, but it matches what all other ports do :)

> src/hotspot/share/runtime/arguments.cpp line 4208:
> 
>> 4206: #endif // COMPILER2
>> 4207: 
>> 4208: 
> 
> Unnecessary changes, that bring one more file to diff list. 
> Please fix.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From rrich at openjdk.java.net  Fri Jun  3 20:37:22 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 3 Jun 2022 20:37:22 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
 <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>
Message-ID: <wYoFws1KaXkfpKFfcVrR5bVN3m6R7DuJg4fulLa5zJQ=.969fe945-d98c-4a9f-9b11-4039a99599b5@github.com>

On Fri, 3 Jun 2022 16:00:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Good.

Thank's for the reviews Aleksey and Vladimir.
I've got 2 weeks off now. Will integrate when back.

Richard.

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From dlong at openjdk.java.net  Sat Jun  4 01:14:31 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 4 Jun 2022 01:14:31 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
Message-ID: <1id0AtAL5Ux5ZhRL2HkgiOJ0amJycNFhUAnR9fsVbTA=.af3bca67-32e6-4e5f-b9ea-1a1825fec65d@github.com>

On Fri, 3 Jun 2022 18:01:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> 8263377: Store method handle linkers in the 'non-nmethods' heap
>
> src/hotspot/share/code/codeBlob.cpp line 342:
> 
>> 340: MethodHandleIntrinsicBlob* MethodHandleIntrinsicBlob::create(const methodHandle& method,
>> 341:   CodeBuffer *code_buffer) {
>> 342:   code_buffer->finalize_oop_references(method);
> 
> Can you please explain why this is needed? (I'm a bit surprised since the constructor asserts that `total_oop_size` is 0)
> 
> Thanks.

I don't think finalize_oop_references() makes sense except for nmethods.  If the MH intrinsic could contain contain oops, then GC would need to be able to find and relocate them.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From dlong at openjdk.java.net  Sat Jun  4 01:27:24 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 4 Jun 2022 01:27:24 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <FPizopcQv2dW0kARitd4brTB5vORQlE9qLwQ-n_FuAE=.ea568fab-177d-4c91-96b8-691bb318a8d8@github.com>

On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8263377: Store method handle linkers in the 'non-nmethods' heap

I don't think we need a new RuntimeBlob subclasses.  Can't we use the existing AdapterBlob or MethodHandlesAdapterBlob?

When changing from nmethod to CodeBlob, don't we need to replace COMPILED_METHOD_LOAD JVMTI events with DYNAMIC_CODE_GENERATED events?

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From dlong at openjdk.java.net  Sat Jun  4 01:46:34 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 4 Jun 2022 01:46:34 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <F0Wc_MyttnViU9WIZ04gWoii-mCpWaDyGfoWyAV0slY=.d9c0e4cd-4a8a-414c-9ff5-5cb6db0736e1@github.com>

On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8263377: Store method handle linkers in the 'non-nmethods' heap

Looking at all the CompiledMethod --> CodeBlob changes, I wondering if it wouldn't be better to use a subclass of CompiledMethod, liked we did for AOT methods.  However, there may be assumptions in the code that the only subclass of CompiledMethod is nmethod.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From dlong at openjdk.java.net  Sat Jun  4 02:05:39 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 4 Jun 2022 02:05:39 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <9C9P4NROYxVuWTJejFnYwQOGPovUstzWACIboIQWTDw=.2977b16b-c175-4774-97af-60071b805f46@github.com>

On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8263377: Store method handle linkers in the 'non-nmethods' heap

src/hotspot/share/ci/ciMethod.cpp line 1146:

> 1144:     CodeBlob* code = get_Method()->code();
> 1145:     if (code != NULL && code->is_compiled()) {
> 1146:       code->as_compiled_method()->log_identity(log);

Doesn't this change the log output?

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From jiefu at openjdk.java.net  Sat Jun  4 05:01:03 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 05:01:03 GMT
Subject: RFR: 8287830: gtest fails to compile after JDK-8287661
Message-ID: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>

Hi all,

gtest fails to compile when configured with `--with-debug-level=optimized`.

This is because for `optimized` no `PRODUCT` is defined.

ifeq ($(DEBUG_LEVEL), release)
  # For hotspot, release builds differ internally between "optimized" and "product"
  # in that "optimize" does not define PRODUCT.
  ifneq ($(HOTSPOT_DEBUG_LEVEL), optimized)
    JVM_CFLAGS_DEBUGLEVEL := -DPRODUCT
  endif


And the `test` log tag is only defined for DEBUG versions.

  LOG_TAG(table) \
  LOG_TAG(task) \
  DEBUG_ONLY(LOG_TAG(test)) \
  LOG_TAG(thread) \
  LOG_TAG(throttle) \


So let's fix it.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8287830: gtest fails to compile after JDK-8287661

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

PR: https://git.openjdk.java.net/jdk/pull/9029

From jiefu at openjdk.java.net  Sat Jun  4 05:04:26 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 05:04:26 GMT
Subject: RFR: 8287661: Fix and improve BitMap::print_on(outputStream*) [v2]
In-Reply-To: <ilMz6BFaIN9i4hbwtLgSYhtgft1TCwYcqa4NfQ4AKfM=.4fee41e3-63fb-490e-9e94-5b194f9846af@github.com>
References: <k1kYRvAGzYfK_rr0MimPN85vGdp9sOX4KSmaGeLQCeU=.76a0b266-d83b-4be3-aec8-a1da02e6d5f2@github.com>
 <G6ur2IXsUhFH8LqyxWDrT1fBZC7vMJk6cxfM8GsGDdA=.68e16ace-5def-4f3a-9f9c-5ea5f5e83dfc@github.com>
 <ilMz6BFaIN9i4hbwtLgSYhtgft1TCwYcqa4NfQ4AKfM=.4fee41e3-63fb-490e-9e94-5b194f9846af@github.com>
Message-ID: <iAqFIHbfFfxcleZ6coCiZcM0FtOQjRuXTRmNQOG1zHA=.bf77acab-05a1-4309-bb89-2913e14a0c0a@github.com>

On Thu, 2 Jun 2022 18:14:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Any other opinions? I'll integrate it otherwise.

There seems to be a regression: https://github.com/openjdk/jdk/pull/9029 .
Please have a look.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8970

From shade at openjdk.java.net  Sat Jun  4 05:50:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 4 Jun 2022 05:50:31 GMT
Subject: RFR: 8287830: gtest fails to compile after JDK-8287661
In-Reply-To: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>
References: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>
Message-ID: <eCvfhId3ccDPJ_H2TXN8bnNRNP3MN2QGTe3EfQXL7ns=.ffd65a5e-37a7-4e92-aedc-4f029c177a70@github.com>

On Sat, 4 Jun 2022 04:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> gtest fails to compile when configured with `--with-debug-level=optimized`.
> 
> This is because for `optimized` no `PRODUCT` is defined.
> 
> ifeq ($(DEBUG_LEVEL), release)
>   # For hotspot, release builds differ internally between "optimized" and "product"
>   # in that "optimize" does not define PRODUCT.
>   ifneq ($(HOTSPOT_DEBUG_LEVEL), optimized)
>     JVM_CFLAGS_DEBUGLEVEL := -DPRODUCT
>   endif
> 
> 
> And the `test` log tag is only defined for DEBUG versions.
> 
>   LOG_TAG(table) \
>   LOG_TAG(task) \
>   DEBUG_ONLY(LOG_TAG(test)) \
>   LOG_TAG(thread) \
>   LOG_TAG(throttle) \
> 
> 
> So let's fix it.
> 
> Thanks.
> Best regards,
> Jie

Looks good and trivial, thanks.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9029

From shade at openjdk.java.net  Sat Jun  4 05:52:24 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 4 Jun 2022 05:52:24 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <wYoFws1KaXkfpKFfcVrR5bVN3m6R7DuJg4fulLa5zJQ=.969fe945-d98c-4a9f-9b11-4039a99599b5@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
 <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>
 <wYoFws1KaXkfpKFfcVrR5bVN3m6R7DuJg4fulLa5zJQ=.969fe945-d98c-4a9f-9b11-4039a99599b5@github.com>
Message-ID: <-qrcsbvKZutU1iJKMk6OjVzV_-z16X3U5MaUX6y5Jhw=.9776ca28-e680-4b74-a049-0e92ea242f9e@github.com>

On Fri, 3 Jun 2022 20:34:03 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> Thank's for the reviews Aleksey and Vladimir. I've got 2 weeks off now. Will integrate when back.

In two weeks, we are going to be in RDP1, so this issue might not be integratable then. I think this issue is simple enough to push now, and the risk for it is small.

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From jiefu at openjdk.java.net  Sat Jun  4 06:50:33 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 06:50:33 GMT
Subject: RFR: 8287830: gtest fails to compile after JDK-8287661
In-Reply-To: <eCvfhId3ccDPJ_H2TXN8bnNRNP3MN2QGTe3EfQXL7ns=.ffd65a5e-37a7-4e92-aedc-4f029c177a70@github.com>
References: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>
 <eCvfhId3ccDPJ_H2TXN8bnNRNP3MN2QGTe3EfQXL7ns=.ffd65a5e-37a7-4e92-aedc-4f029c177a70@github.com>
Message-ID: <T2w4eEMd17mwiVbldMUFhF-JRdgXG10K1H2J_Og8I2s=.32e5a109-1197-4c44-88c0-fb74fa96ac7e@github.com>

On Sat, 4 Jun 2022 05:47:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks good and trivial, thanks.

Thanks @shipilev for your review.

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

PR: https://git.openjdk.java.net/jdk/pull/9029

From jiefu at openjdk.java.net  Sat Jun  4 06:50:34 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 4 Jun 2022 06:50:34 GMT
Subject: Integrated: 8287830: gtest fails to compile after JDK-8287661
In-Reply-To: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>
References: <zBMHIrdcTVRQApCOqhB2tMT3aBm0duFNIIeP0OjNjTE=.be6e3c81-4439-452e-83a6-91795ab18e95@github.com>
Message-ID: <GBazV2fmYgf-Cplr0-N6T-Mgu19z2hAxx6KOtruwnhw=.eb9a8dd1-9d38-4763-befd-aa9680d94297@github.com>

On Sat, 4 Jun 2022 04:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> gtest fails to compile when configured with `--with-debug-level=optimized`.
> 
> This is because for `optimized` no `PRODUCT` is defined.
> 
> ifeq ($(DEBUG_LEVEL), release)
>   # For hotspot, release builds differ internally between "optimized" and "product"
>   # in that "optimize" does not define PRODUCT.
>   ifneq ($(HOTSPOT_DEBUG_LEVEL), optimized)
>     JVM_CFLAGS_DEBUGLEVEL := -DPRODUCT
>   endif
> 
> 
> And the `test` log tag is only defined for DEBUG versions.
> 
>   LOG_TAG(table) \
>   LOG_TAG(task) \
>   DEBUG_ONLY(LOG_TAG(test)) \
>   LOG_TAG(thread) \
>   LOG_TAG(throttle) \
> 
> 
> So let's fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: a113e166
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a113e166e91b9b3d3f74a284888a5135b48dad44
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8287830: gtest fails to compile after JDK-8287661

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/9029

From rrich at openjdk.java.net  Sat Jun  4 13:37:25 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sat, 4 Jun 2022 13:37:25 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <-qrcsbvKZutU1iJKMk6OjVzV_-z16X3U5MaUX6y5Jhw=.9776ca28-e680-4b74-a049-0e92ea242f9e@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
 <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>
 <wYoFws1KaXkfpKFfcVrR5bVN3m6R7DuJg4fulLa5zJQ=.969fe945-d98c-4a9f-9b11-4039a99599b5@github.com>
 <-qrcsbvKZutU1iJKMk6OjVzV_-z16X3U5MaUX6y5Jhw=.9776ca28-e680-4b74-a049-0e92ea242f9e@github.com>
Message-ID: <587IXzqFThelQpPNx4qb3BhvkWrt4LwFAfoZKr7gXFc=.02317788-f81d-422b-b3fd-89663e07acee@github.com>

On Sat, 4 Jun 2022 05:49:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Thank's for the reviews Aleksey and Vladimir. I've got 2 weeks off now. Will integrate when back.
> 
> 
> 
> In two weeks, we are going to be in RDP1, so this issue might not be integratable then. I think this issue is simple enough to push now, and the risk for it is small.

I agree, the risk is small (as the gain is). But maybe it blocks your changes? Do you want me to push now? You could also include this small enhancement in your work and I'd close this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From wkudla.kernel at gmail.com  Sun Jun  5 09:31:21 2022
From: wkudla.kernel at gmail.com (Wojciech Kudla)
Date: Sun, 5 Jun 2022 10:31:21 +0100
Subject: Obsoleting JavaCritical
Message-ID: <CADV2yPnOAO9kqgLhJt01oBe+XdX2-EN+RN1K=PbdbqAuivkL1g@mail.gmail.com>

Hi everyone,

I raised this issue with Coleen Phillimore who suggested I forward my email
to hotspot-dev/jdk-dev...

Just wanted to let you know that obsoleting Critical JNI natives is going
to have a very detrimental impact on performance of latency-critical
software in a few domains like HPC, HFT or systematic market making.
We heavily exploit this feature and our use case has nothing to do with
arrays or otherwise slippery scenarios involving JVM-controlled memory. The
simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
resolution timestamp. Some shops in our industry also replace parts of NIO
with hand-crafted native code for example to get access to syscalls such as
recvmsg/recvmmsg (either to get hardware timestamps or batch receive or any
other functionality otherwise unavailable in the JDK.

JavaCritical_ variant of the native implementation is nearly 30% faster for
extremely short calls like the cases mentioned above compared to the
standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23 nanos
vs 33 nanos on my box but I assure you we make a large number of such calls
in our industry and this just compounds.
Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and get
the desired performance but I just checked a jdk18 build and the cost of
these calls is back at 33 nanos so this is performance regression.

JavaCritical is an important part of making Java successful in high
performance-focused areas and taking a step back with more restrictive
approach in Panama would be a blow to the perception of the platform and
its value in our field. I'd be more than happy to provide more context if
needed. I realize things are fluid and there's probably still a lot of work
in progress, but wanted to make you guys aware JavaCritical is not some
forgotten feature no one uses. There's a whole industry and scientific
research that relies on this.

Thanks,
Wojciech Kudla

From shade at openjdk.java.net  Sun Jun  5 13:41:24 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sun, 5 Jun 2022 13:41:24 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <587IXzqFThelQpPNx4qb3BhvkWrt4LwFAfoZKr7gXFc=.02317788-f81d-422b-b3fd-89663e07acee@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
 <vXac1CBIHtPnl5kk8-d3N_mPBtmDUD1M1mLzNohIJQM=.ea196ee8-eac3-45cb-ab86-cd3c60d4b60b@github.com>
 <wYoFws1KaXkfpKFfcVrR5bVN3m6R7DuJg4fulLa5zJQ=.969fe945-d98c-4a9f-9b11-4039a99599b5@github.com>
 <-qrcsbvKZutU1iJKMk6OjVzV_-z16X3U5MaUX6y5Jhw=.9776ca28-e680-4b74-a049-0e92ea242f9e@github.com>
 <587IXzqFThelQpPNx4qb3BhvkWrt4LwFAfoZKr7gXFc=.02317788-f81d-422b-b3fd-89663e07acee@github.com>
Message-ID: <XHTf4IfHMRppe5_8Zy2zvrI_Td1doRjTQWQmlcyMwJ4=.a3594210-7f28-4325-86cf-4f2c26829659@github.com>

On Sat, 4 Jun 2022 13:33:57 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > > Thank's for the reviews Aleksey and Vladimir. I've got 2 weeks off now. Will integrate when back.
> > 
> > 
> > In two weeks, we are going to be in RDP1, so this issue might not be integratable then. I think this issue is simple enough to push now, and the risk for it is small.
> 
> I agree, the risk is small (as the gain is). But maybe it blocks your changes? Do you want me to push now? You could also include this small enhancement in your work and I'd close this PR.

Just push it now. I will handle the fallout, if any, while you are away. Other arches are likely to use x86_64 code as the template, so minor differences would accumulate if we delay this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From duke at openjdk.java.net  Sun Jun  5 16:04:19 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Sun, 5 Jun 2022 16:04:19 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
Message-ID: <Tu_NsqUIFnjEPcKvMiPQYk0wUiGBUggvcf2fBMgSqTE=.b9133e1f-0263-4b20-864e-c89a8d9f1efd@github.com>

On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - do_thread(target) not self
>  - Remove checks for is_handshake_for, instead call Handshake::execute
>  - Switch order of handshake check

Passed tier1-5.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From rrich at openjdk.java.net  Sun Jun  5 19:32:53 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 5 Jun 2022 19:32:53 GMT
Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to
 exception handler [v2]
In-Reply-To: <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
 <vKRklUAhyuUStNGzuhIX-I18rha92d8K7XpG31Px1oo=.c5cf7d0d-73d6-4fe5-b3d4-c58436c498ff@github.com>
Message-ID: <G3eMu5iSt6MF5FBTKxWLyCml9Ljkld_OwjTO8gi1pXI=.3f71e28b-bba2-4652-8736-e648f2b4d61a@github.com>

On Fri, 3 Jun 2022 07:57:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()`
>> 
>> Testing:
>> 
>> jtreg:test/hotspot/jtreg:hotspot_loom
>> jtreg:test/jdk:jdk_loom
>> 
>> On linux x86_64 and aarch64.
>> 
>> On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
>  - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw
>  - Remove dead code from generate_cont_thaw

Sure. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From rrich at openjdk.java.net  Sun Jun  5 19:32:54 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 5 Jun 2022 19:32:54 GMT
Subject: Integrated: 8287205: generate_cont_thaw generates dead code after jump
 to exception handler
In-Reply-To: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
References: <S4ETtvCKVyYmERllHQn-_PvBfyfkEoPQj0SAdKJT-qM=.c0ad7bb7-69b9-4c7e-a8a5-836dff01f558@github.com>
Message-ID: <XDlfUo0t1XrC6ESCZjGNXJCHujU4WzIWoIzb5eVeurI=.219c40de-4c68-4ebc-9dd3-e32fe2b655c5@github.com>

On Tue, 24 May 2022 07:33:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()`
> 
> Testing:
> 
> jtreg:test/hotspot/jtreg:hotspot_loom
> jtreg:test/jdk:jdk_loom
> 
> On linux x86_64 and aarch64.
> 
> On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout.

This pull request has now been integrated.

Changeset: ebc012ec
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ebc012ece28ea731c4756cab2374ebecfa5ac1a3
Stats:     16 lines in 2 files changed: 8 ins; 8 del; 0 mod

8287205: generate_cont_thaw generates dead code after jump to exception handler

Reviewed-by: shade, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/8863

From Alan.Bateman at oracle.com  Sun Jun  5 20:02:37 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 5 Jun 2022 21:02:37 +0100
Subject: Obsoleting JavaCritical
In-Reply-To: <CADV2yPnOAO9kqgLhJt01oBe+XdX2-EN+RN1K=PbdbqAuivkL1g@mail.gmail.com>
References: <CADV2yPnOAO9kqgLhJt01oBe+XdX2-EN+RN1K=PbdbqAuivkL1g@mail.gmail.com>
Message-ID: <58b23d0e-00f9-f3e6-ec32-f3b005a2c3a8@oracle.com>

On 05/06/2022 10:31, Wojciech Kudla wrote:
> :
>
> JavaCritical is an important part of making Java successful in high
> performance-focused areas and taking a step back with more restrictive
> approach in Panama would be a blow to the perception of the platform and
> its value in our field. I'd be more than happy to provide more context if
> needed. I realize things are fluid and there's probably still a lot of work
> in progress, but wanted to make you guys aware JavaCritical is not some
> forgotten feature no one uses. There's a whole industry and scientific
> research that relies on this.
>
As I recall, this was a JDK internal and undocumented jetpack used by 
code such as the Solaris ucrypto provider. It's unfortunate that it 
found its way into answers on StackOverflow and code in important fields 
starting to rely on it.

I think it would be best to start a discussion on panama-dev as the 
desire to invoke syscalls that promise not to block is understood there.

-Alan

From maurizio.cimadamore at oracle.com  Sun Jun  5 21:52:16 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 5 Jun 2022 22:52:16 +0100
Subject: Obsoleting JavaCritical
In-Reply-To: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
Message-ID: <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>

(adding hotspot-dev)

Hi Wojciech,
it is not the goal of Project Panama to obsolete Critical JNI. What we 
would like to do is, obviously, over time, get to a similar level of 
performance (as discussed elsewhere in this mailing list recently, see [1]).

It is possible that there might be other ways to get to the same level 
(or better) of performance than the one you have (I understand that this 
is especially the case with clock_gettime, for which an intrinsified 
alternative is available in the JDK - System.nanoTime) - in general 
using native calls for things that only contains a bunch of machine 
instruction is always going to be painful.

That said, I'd like somebody on the hotspot team to add more background 
on the decision of dropping support for JNI critical in 18.

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2022-June/017046.html

On 05/06/2022 22:25, Wojciech Kudla wrote:
> Hi everyone,
>
> Just wanted to let you know that obsoleting Critical JNI natives is going
> to have a very detrimental impact on performance of latency-critical
> software in a few domains like HPC, HFT or systematic market making.
> We heavily exploit this feature and our use case has nothing to do with
> arrays or otherwise slippery scenarios involving JVM-controlled memory. The
> simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
> resolution timestamp. Some shops in our industry also replace parts of NIO
> with hand-crafted native code for example to get access to syscalls such as
> recvmsg/recvmmsg (either to get hardware timestamps or batch receive or any
> other functionality otherwise unavailable in the JDK.
>
> JavaCritical_ variant of the native implementation is nearly 30% faster for
> extremely short calls like the cases mentioned above compared to the
> standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23 nanos
> vs 33 nanos on my box but I assure you we make a large number of such calls
> in our industry and this just compounds.
> Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and get
> the desired performance but I just checked a jdk18 build and the cost of
> these calls is back at 33 nanos so this is performance regression.
>
> JavaCritical is an important part of making Java successful in high
> performance-focused areas and taking a step back with more restrictive
> approach in Panama would be a blow to the perception of the platform and
> its value in our field. I'd be more than happy to provide more context if
> needed. I realize things are fluid and there's probably still a lot of work
> in progress, but wanted to make you guys aware JavaCritical is not some
> forgotten feature no one uses. There's a whole industry and scientific
> research that relies on this.
>
> Thanks,
> Wojciech Kudla

From xgong at openjdk.java.net  Mon Jun  6 01:38:29 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 6 Jun 2022 01:38:29 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
 <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>
 <FgMe5IaeBjJT9Lt4g19NKQlqcgYadJkvLHyCz_vNJ6c=.42322acb-1637-4213-987f-ccbd9f7e57d5@github.com>
 <7BACvqeUZFJbVq36mElnVBWg2vXyN6kVUXYNKvJ7cuA=.a04e6924-006b-43f3-adec-97132d5a719d@github.com>
Message-ID: <ISDc8AYKbO25Ifkr3Y06wmmwwXn7n_jMo41lMN_ivgI=.fe4d2691-f6b8-4ed6-9d08-c39a339a8d79@github.com>

On Thu, 2 Jun 2022 03:24:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
>
>> > @XiaohongGong Could you please rebase the branch and resolve conflicts?
>> 
>> Sure, I'm working on this now. The patch will be updated soon. Thanks.
> 
> Resolved the conflicts. Thanks!

> @XiaohongGong You need one more review approval.

Sure! Thanks a lot for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Mon Jun  6 01:38:31 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 6 Jun 2022 01:38:31 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <qyQ0J7SUfPXP3d7jUJ3YnbyNBvgkEsJAqZjl1I5rkOY=.408e2c88-2463-48e5-83e3-d2136e7b3582@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> 
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

Hi @PaulSandoz , could you please take a look at this PR again? Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From wkudla.kernel at gmail.com  Mon Jun  6 06:34:00 2022
From: wkudla.kernel at gmail.com (Wojciech Kudla)
Date: Mon, 6 Jun 2022 07:34:00 +0100
Subject: Obsoleting JavaCritical
In-Reply-To: <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
Message-ID: <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>

Thank you Maurizio,

We're hopeful things will improve with time in the next few Java releases
and can afford to stick to JDK17 for the time skipping a two or three
versions down the road if that means maintaining performance levels our
industry requires.
As for intrinsified calls: sadly System.nanoTime() is not an alternative to
clock_gettime(CLOCK_REALTIME) as they return different time. The JDK
obtains CLOCK_MONOTONIC IIRC.

Thanks,
W.

On Sun, Jun 5, 2022 at 10:52 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> (adding hotspot-dev)
>
> Hi Wojciech,
> it is not the goal of Project Panama to obsolete Critical JNI. What we
> would like to do is, obviously, over time, get to a similar level of
> performance (as discussed elsewhere in this mailing list recently, see
> [1]).
>
> It is possible that there might be other ways to get to the same level
> (or better) of performance than the one you have (I understand that this
> is especially the case with clock_gettime, for which an intrinsified
> alternative is available in the JDK - System.nanoTime) - in general
> using native calls for things that only contains a bunch of machine
> instruction is always going to be painful.
>
> That said, I'd like somebody on the hotspot team to add more background
> on the decision of dropping support for JNI critical in 18.
>
> [1] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2022-June/017046.html
>
> On 05/06/2022 22:25, Wojciech Kudla wrote:
> > Hi everyone,
> >
> > Just wanted to let you know that obsoleting Critical JNI natives is going
> > to have a very detrimental impact on performance of latency-critical
> > software in a few domains like HPC, HFT or systematic market making.
> > We heavily exploit this feature and our use case has nothing to do with
> > arrays or otherwise slippery scenarios involving JVM-controlled memory.
> The
> > simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
> > resolution timestamp. Some shops in our industry also replace parts of
> NIO
> > with hand-crafted native code for example to get access to syscalls such
> as
> > recvmsg/recvmmsg (either to get hardware timestamps or batch receive or
> any
> > other functionality otherwise unavailable in the JDK.
> >
> > JavaCritical_ variant of the native implementation is nearly 30% faster
> for
> > extremely short calls like the cases mentioned above compared to the
> > standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23 nanos
> > vs 33 nanos on my box but I assure you we make a large number of such
> calls
> > in our industry and this just compounds.
> > Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and get
> > the desired performance but I just checked a jdk18 build and the cost of
> > these calls is back at 33 nanos so this is performance regression.
> >
> > JavaCritical is an important part of making Java successful in high
> > performance-focused areas and taking a step back with more restrictive
> > approach in Panama would be a blow to the perception of the platform and
> > its value in our field. I'd be more than happy to provide more context if
> > needed. I realize things are fluid and there's probably still a lot of
> work
> > in progress, but wanted to make you guys aware JavaCritical is not some
> > forgotten feature no one uses. There's a whole industry and scientific
> > research that relies on this.
> >
> > Thanks,
> > Wojciech Kudla
>

From shade at openjdk.java.net  Mon Jun  6 06:41:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 06:41:29 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads) [v2]
In-Reply-To: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
Message-ID: <3qEjx53XCpnsDlKPo3UryEZmMFtMa_csftyXDBgWwe4=.def3d695-3e98-4f92-a185-e1a31668e815@github.com>

> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
> 
> Additional testing:
>  - [x] Linux arm32 fastdebug build
>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass

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

 - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
 - Whitespace and comments
 - JFR barriers from Sergey
 - Cleanups
 - Flesh out generate_jfr_write_checkpoint a bit (untested)
 - Match the generator shape to x86_64
 - C2 patch from Sergey
 - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
 - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
 - ARM32 bootstraps fine without C2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8634/files
  - new: https://git.openjdk.java.net/jdk/pull/8634/files/dff69a64..0eb6f85f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8634&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8634&range=00-01

  Stats: 10069 lines in 203 files changed: 8448 ins; 1137 del; 484 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8634/head:pull/8634

PR: https://git.openjdk.java.net/jdk/pull/8634

From david.holmes at oracle.com  Mon Jun  6 06:44:58 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 6 Jun 2022 16:44:58 +1000
Subject: Obsoleting JavaCritical
In-Reply-To: <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
Message-ID: <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>

On 6/06/2022 4:34 pm, Wojciech Kudla wrote:
> Thank you Maurizio,
> 
> We're hopeful things will improve with time in the next few Java releases
> and can afford to stick to JDK17 for the time skipping a two or three
> versions down the road if that means maintaining performance levels our
> industry requires.
> As for intrinsified calls: sadly System.nanoTime() is not an alternative to
> clock_gettime(CLOCK_REALTIME) as they return different time. The JDK
> obtains CLOCK_MONOTONIC IIRC.

Yes for System.nanoTime(), but System.currentTimeMillis() reports 
CLOCK_REALTIME.

This CriticalJNINatives mechanism was not intended for general use and 
was not supported in any real sense. If your "critical" native does not 
behave well then it can cause issues with GC and safepoints in general. 
A supported mechanism needs to be at least moderately safe (this is 
native code so full safety is not achievable), but it would come down to 
convention more than enforcement. And as raised in other threads on 
this, perhaps what is really wanted is a way to inline, or intrinsify, 
your own native code, rather than just trying to make slow native calls 
slightly faster.

Cheers,
David
-----

> Thanks,
> W.
> 
> On Sun, Jun 5, 2022 at 10:52 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
> 
>> (adding hotspot-dev)
>>
>> Hi Wojciech,
>> it is not the goal of Project Panama to obsolete Critical JNI. What we
>> would like to do is, obviously, over time, get to a similar level of
>> performance (as discussed elsewhere in this mailing list recently, see
>> [1]).
>>
>> It is possible that there might be other ways to get to the same level
>> (or better) of performance than the one you have (I understand that this
>> is especially the case with clock_gettime, for which an intrinsified
>> alternative is available in the JDK - System.nanoTime) - in general
>> using native calls for things that only contains a bunch of machine
>> instruction is always going to be painful.
>>
>> That said, I'd like somebody on the hotspot team to add more background
>> on the decision of dropping support for JNI critical in 18.
>>
>> [1] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2022-June/017046.html
>>
>> On 05/06/2022 22:25, Wojciech Kudla wrote:
>>> Hi everyone,
>>>
>>> Just wanted to let you know that obsoleting Critical JNI natives is going
>>> to have a very detrimental impact on performance of latency-critical
>>> software in a few domains like HPC, HFT or systematic market making.
>>> We heavily exploit this feature and our use case has nothing to do with
>>> arrays or otherwise slippery scenarios involving JVM-controlled memory.
>> The
>>> simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
>>> resolution timestamp. Some shops in our industry also replace parts of
>> NIO
>>> with hand-crafted native code for example to get access to syscalls such
>> as
>>> recvmsg/recvmmsg (either to get hardware timestamps or batch receive or
>> any
>>> other functionality otherwise unavailable in the JDK.
>>>
>>> JavaCritical_ variant of the native implementation is nearly 30% faster
>> for
>>> extremely short calls like the cases mentioned above compared to the
>>> standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23 nanos
>>> vs 33 nanos on my box but I assure you we make a large number of such
>> calls
>>> in our industry and this just compounds.
>>> Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and get
>>> the desired performance but I just checked a jdk18 build and the cost of
>>> these calls is back at 33 nanos so this is performance regression.
>>>
>>> JavaCritical is an important part of making Java successful in high
>>> performance-focused areas and taking a step back with more restrictive
>>> approach in Panama would be a blow to the perception of the platform and
>>> its value in our field. I'd be more than happy to provide more context if
>>> needed. I realize things are fluid and there's probably still a lot of
>> work
>>> in progress, but wanted to make you guys aware JavaCritical is not some
>>> forgotten feature no one uses. There's a whole industry and scientific
>>> research that relies on this.
>>>
>>> Thanks,
>>> Wojciech Kudla
>>

From wkudla.kernel at gmail.com  Mon Jun  6 07:24:17 2022
From: wkudla.kernel at gmail.com (Wojciech Kudla)
Date: Mon, 6 Jun 2022 08:24:17 +0100
Subject: Obsoleting JavaCritical
In-Reply-To: <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
Message-ID: <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>

> Yes for System.nanoTime(), but System.currentTimeMillis() reports
CLOCK_REALTIME.

Unfortunately System.currentTimeMillis() offers only millisecond
granularity which is the reason why our industry has to resort to
clock_gettime.
Agreed on the nature of this capability and possible consequences. You can
already use a single line of JNI or Unsafe to crash the JVM but this is
clearly signalled by the platform's documentation and been the status quo
for a very long time.
There are groups of developers competent enough to extract a lot of value
from consciously running with scissors.

I've had a look at the discussions and ideas pointed to by Maurizio and
agree with you David, that intrinsifying/inlining on demand would be ideal
here.
So far this has only been possible by forking Openjdk. Are there any plans
to allow this in a pluggable way?
It looks like Vladimir Ivanov was on the right track:
http://mail.openjdk.java.net/pipermail/panama-dev/2015-December/000225.html

Thanks,
W.

On Mon, Jun 6, 2022 at 7:45 AM David Holmes <david.holmes at oracle.com> wrote:

> On 6/06/2022 4:34 pm, Wojciech Kudla wrote:
> > Thank you Maurizio,
> >
> > We're hopeful things will improve with time in the next few Java releases
> > and can afford to stick to JDK17 for the time skipping a two or three
> > versions down the road if that means maintaining performance levels our
> > industry requires.
> > As for intrinsified calls: sadly System.nanoTime() is not an alternative
> to
> > clock_gettime(CLOCK_REALTIME) as they return different time. The JDK
> > obtains CLOCK_MONOTONIC IIRC.
>
> Yes for System.nanoTime(), but System.currentTimeMillis() reports
> CLOCK_REALTIME.
>
> This CriticalJNINatives mechanism was not intended for general use and
> was not supported in any real sense. If your "critical" native does not
> behave well then it can cause issues with GC and safepoints in general.
> A supported mechanism needs to be at least moderately safe (this is
> native code so full safety is not achievable), but it would come down to
> convention more than enforcement. And as raised in other threads on
> this, perhaps what is really wanted is a way to inline, or intrinsify,
> your own native code, rather than just trying to make slow native calls
> slightly faster.
>
> Cheers,
> David
> -----
>
> > Thanks,
> > W.
> >
> > On Sun, Jun 5, 2022 at 10:52 PM Maurizio Cimadamore <
> > maurizio.cimadamore at oracle.com> wrote:
> >
> >> (adding hotspot-dev)
> >>
> >> Hi Wojciech,
> >> it is not the goal of Project Panama to obsolete Critical JNI. What we
> >> would like to do is, obviously, over time, get to a similar level of
> >> performance (as discussed elsewhere in this mailing list recently, see
> >> [1]).
> >>
> >> It is possible that there might be other ways to get to the same level
> >> (or better) of performance than the one you have (I understand that this
> >> is especially the case with clock_gettime, for which an intrinsified
> >> alternative is available in the JDK - System.nanoTime) - in general
> >> using native calls for things that only contains a bunch of machine
> >> instruction is always going to be painful.
> >>
> >> That said, I'd like somebody on the hotspot team to add more background
> >> on the decision of dropping support for JNI critical in 18.
> >>
> >> [1] -
> >>
> https://mail.openjdk.java.net/pipermail/panama-dev/2022-June/017046.html
> >>
> >> On 05/06/2022 22:25, Wojciech Kudla wrote:
> >>> Hi everyone,
> >>>
> >>> Just wanted to let you know that obsoleting Critical JNI natives is
> going
> >>> to have a very detrimental impact on performance of latency-critical
> >>> software in a few domains like HPC, HFT or systematic market making.
> >>> We heavily exploit this feature and our use case has nothing to do with
> >>> arrays or otherwise slippery scenarios involving JVM-controlled memory.
> >> The
> >>> simplest example is calling clock_gettime(CLOCK_REALTIME) to get a high
> >>> resolution timestamp. Some shops in our industry also replace parts of
> >> NIO
> >>> with hand-crafted native code for example to get access to syscalls
> such
> >> as
> >>> recvmsg/recvmmsg (either to get hardware timestamps or batch receive or
> >> any
> >>> other functionality otherwise unavailable in the JDK.
> >>>
> >>> JavaCritical_ variant of the native implementation is nearly 30% faster
> >> for
> >>> extremely short calls like the cases mentioned above compared to the
> >>> standard JNI impl. In case of clock_gettime(CLOCK_REALTIME) it's 23
> nanos
> >>> vs 33 nanos on my box but I assure you we make a large number of such
> >> calls
> >>> in our industry and this just compounds.
> >>> Luckily with jdk17 we can still run with -XX:+CriticalJNINatives and
> get
> >>> the desired performance but I just checked a jdk18 build and the cost
> of
> >>> these calls is back at 33 nanos so this is performance regression.
> >>>
> >>> JavaCritical is an important part of making Java successful in high
> >>> performance-focused areas and taking a step back with more restrictive
> >>> approach in Panama would be a blow to the perception of the platform
> and
> >>> its value in our field. I'd be more than happy to provide more context
> if
> >>> needed. I realize things are fluid and there's probably still a lot of
> >> work
> >>> in progress, but wanted to make you guys aware JavaCritical is not some
> >>> forgotten feature no one uses. There's a whole industry and scientific
> >>> research that relies on this.
> >>>
> >>> Thanks,
> >>> Wojciech Kudla
> >>
>

From dholmes at openjdk.java.net  Mon Jun  6 07:36:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Jun 2022 07:36:39 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
Message-ID: <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>

On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - do_thread(target) not self
>  - Remove checks for is_handshake_for, instead call Handshake::execute
>  - Switch order of handshake check

Hi Johan,

I like the idea of this, but am not clear on all the details for all possible cases - see below.

It also makes me wonder about the async case, where `Handshake::execute(AsyncHandshakeClosure*, ...)` never processes the handshake directly even if it is for the current thread. The async case seems to be a two phase protocol:
1. Install async op on yourself
2. At some later handshake state poll discover the op you previously installed.
??

There are a few minor nits/suggestions below as well.

Thanks.

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 399:

> 397:       // so get current location with direct handshake.
> 398:       GetCurrentLocationClosure op;
> 399:       Thread *current = Thread::current();

This appears unused now.

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 401:

> 399:       Thread *current = Thread::current();
> 400:       Handshake::execute(&op, thread);
> 401:       guarantee(op.completed(), "Handshake failed. Target thread is not alive?");

I much prefer that the current-thread case is internalised by `Handshake::execute` now. The code creating the handshake op shouldn't have to worry about current thread or not.

src/hotspot/share/prims/jvmtiEventController.cpp line 370:

> 368:   }
> 369:   EnterInterpOnlyModeClosure hs;
> 370:   assert(state->get_thread() != NULL, "sanity check");

Existing: We have already performed this check. We set `target` above and returned if it was `NULL`.

src/hotspot/share/runtime/handshake.cpp line 357:

> 355:   if (target->is_handshake_safe_for(self)) {
> 356:     hs_cl->do_thread(target);
> 357:     return;

I like the idea of doing this, but I can't quite convince myself that it will always be safe when the target is not the current thread. ??

src/hotspot/share/runtime/handshake.cpp line 360:

> 358:   }
> 359: 
> 360:   HandshakeOperation op(hs_cl, target, Thread::current());

Existing nit: this should pass `self` not re-invoke `Thread::current()`.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8992

From dholmes at openjdk.java.net  Mon Jun  6 07:36:41 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Jun 2022 07:36:41 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
 <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
Message-ID: <gJZ-6xqk8k7a464QbqrDiH_viXGPUyZXRA84OpT9Rzc=.b231678d-1513-4bb3-ab8a-237182730471@github.com>

On Mon, 6 Jun 2022 07:19:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - do_thread(target) not self
>>  - Remove checks for is_handshake_for, instead call Handshake::execute
>>  - Switch order of handshake check
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 370:
> 
>> 368:   }
>> 369:   EnterInterpOnlyModeClosure hs;
>> 370:   assert(state->get_thread() != NULL, "sanity check");
> 
> Existing: We have already performed this check. We set `target` above and returned if it was `NULL`.

We also no longer need L358 as `current` is now unused.

> src/hotspot/share/runtime/handshake.cpp line 360:
> 
>> 358:   }
>> 359: 
>> 360:   HandshakeOperation op(hs_cl, target, Thread::current());
> 
> Existing nit: this should pass `self` not re-invoke `Thread::current()`.

Actually, `self` should be `current` as that is the convention we are trying to use everywhere (some old code still uses 'self').

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From shade at openjdk.java.net  Mon Jun  6 09:23:24 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 09:23:24 GMT
Subject: RFR: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads) [v2]
In-Reply-To: <3qEjx53XCpnsDlKPo3UryEZmMFtMa_csftyXDBgWwe4=.def3d695-3e98-4f92-a185-e1a31668e815@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
 <3qEjx53XCpnsDlKPo3UryEZmMFtMa_csftyXDBgWwe4=.def3d695-3e98-4f92-a185-e1a31668e815@github.com>
Message-ID: <JbmGBHDS0fIjKQa4VC-MgLtfjB17NSXbgnBBUYqLC2Q=.7837f462-252f-4ffb-b3ea-2b6c3d3fc99b@github.com>

On Mon, 6 Jun 2022 06:41:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
>> 
>> Additional testing:
>>  - [x] Linux arm32 fastdebug build
>>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass
>>  - [x] Linux arm32 fastdebug, `jdk_jfr` passes (some timeout failures, because the board I have is very slow)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
>  - Whitespace and comments
>  - JFR barriers from Sergey
>  - Cleanups
>  - Flesh out generate_jfr_write_checkpoint a bit (untested)
>  - Match the generator shape to x86_64
>  - C2 patch from Sergey
>  - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
>  - Merge branch 'master' into JDK-8286360-loom-arm32-no-preview
>  - ARM32 bootstraps fine without C2

All right, any more reviews? I would like to integrate this to unbreak ARM32.

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From shade at openjdk.java.net  Mon Jun  6 10:23:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 10:23:36 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
Message-ID: <WFa0cQew4_ovSFHDePBSOaqfVanflxkcDF7LXvaowUI=.75680b9a-a888-448d-a4c8-b745deb65c2d@github.com>

On Wed, 1 Jun 2022 15:09:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Harmonize exception handler invocation
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Revert test groups
>  - Fix

Still open for reviews, with RDP1 looming. Please review!

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From jbhateja at openjdk.java.net  Mon Jun  6 10:44:50 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 6 Jun 2022 10:44:50 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'jdk:master' into JDK-8283667
>  - Use integer constant for offsetInRange all the way through
>  - Rename "use_predicate" to "needs_predicate"
>  - Rename the "usePred" to "offsetInRange"
>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:

> 95:     public void byteLoadArrayMaskIOOBE() {
> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);

For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From rpressler at openjdk.java.net  Mon Jun  6 12:27:57 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Mon, 6 Jun 2022 12:27:57 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
Message-ID: <JcsCed7Ajg5wPcePHbnFymNbjq1ruQPhc1oo3M6N9SI=.d713224a-7d2b-435f-9645-7ac4282c1608@github.com>

On Wed, 1 Jun 2022 15:09:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Harmonize exception handler invocation
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Revert test groups
>  - Fix

Looks fine. Thanks.

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

Marked as reviewed by rpressler (Author).

PR: https://git.openjdk.java.net/jdk/pull/8802

From pchilanomate at openjdk.java.net  Mon Jun  6 14:04:48 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 6 Jun 2022 14:04:48 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
Message-ID: <kdsBCPthZmVG1vzyMOuQvJx9paK0qY1urjLeFBFxEOk=.fb614715-0393-485d-a6b3-1b143be1be44@github.com>

On Wed, 1 Jun 2022 15:09:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Harmonize exception handler invocation
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>  - Revert test groups
>  - Fix

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1276:

> 1274: static void gen_continuation_enter(MacroAssembler* masm,
> 1275:                                  const methodHandle& method,
> 1276:                                  const BasicType* sig_bt,

Should we remove these two parameters? They were used on a commented out line which is now removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From shade at openjdk.java.net  Mon Jun  6 14:30:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 14:30:42 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v5]
In-Reply-To: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
Message-ID: <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>

> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
> 
> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
> 
> Brief tour of changes:
>  - Check the incoming registers explicitly
>  - Pass explicit argument registers to `fill_continuation_entry`
>  - Use the usual `NativeCall` alignment code to produce a patchable call
>  - Check that static stub is emitted, fail hard otherwise
>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`

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

  Review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8802/files
  - new: https://git.openjdk.java.net/jdk/pull/8802/files/3c721970..80960e2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From shade at openjdk.java.net  Mon Jun  6 14:30:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 14:30:46 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v4]
In-Reply-To: <kdsBCPthZmVG1vzyMOuQvJx9paK0qY1urjLeFBFxEOk=.fb614715-0393-485d-a6b3-1b143be1be44@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <0j4o9dhE0FK6fmjwPs5ZAlpD6n6ae2_kodlPUeEJb8g=.cade96f6-b426-4cee-80ff-31d33f9b9389@github.com>
 <kdsBCPthZmVG1vzyMOuQvJx9paK0qY1urjLeFBFxEOk=.fb614715-0393-485d-a6b3-1b143be1be44@github.com>
Message-ID: <STc9m9fOucejRs1oB3WtBoTofY3dUb3FKNrLcUBkgdw=.c9639f72-ac1e-4cb8-9705-02f43d2d3c74@github.com>

On Mon, 6 Jun 2022 14:01:20 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>>  - Harmonize exception handler invocation
>>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>>  - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter
>>  - Revert test groups
>>  - Fix
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 1276:
> 
>> 1274: static void gen_continuation_enter(MacroAssembler* masm,
>> 1275:                                  const methodHandle& method,
>> 1276:                                  const BasicType* sig_bt,
> 
> Should we remove these two parameters? They were used on a commented out line which is now removed.

Yes, we can. See new commit. I guess I should just test the `reg_cont_obj` explicitly instead of trying to call the generic `verify_oop_args`. New version passes `jdk_loom hotspot_loom` with `-XX:+VerifyOops`.

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From pchilanomate at openjdk.java.net  Mon Jun  6 14:36:39 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Mon, 6 Jun 2022 14:36:39 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v5]
In-Reply-To: <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
Message-ID: <TddM1G0-BoQbaYbaPyMrR03xL-PrpyMDJ_FQXbjRGik=.9687fe57-ebb4-40a0-8ace-1c6883ae0f0c@github.com>

On Mon, 6 Jun 2022 14:30:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by pchilanomate (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From psandoz at openjdk.java.net  Mon Jun  6 15:44:50 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 6 Jun 2022 15:44:50 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
Message-ID: <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>

On Thu, 2 Jun 2022 03:27:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'jdk:master' into JDK-8283667
>  - Use integer constant for offsetInRange all the way through
>  - Rename "use_predicate" to "needs_predicate"
>  - Rename the "usePred" to "offsetInRange"
>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

Looks good. As a follow on PR I think it would be useful to add constants `OFFSET_IN_RANGE` and `OFFSET_OUT_OF_RANGE`, then it becomes much clearer in source and you can drop the `/* offsetInRange */` comment on the argument.

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

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8035

From dcubed at openjdk.java.net  Mon Jun  6 20:37:03 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 6 Jun 2022 20:37:03 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
Message-ID: <ssxX-RXofRNgljv5NFORA4cdvZTPGjeNdLrdljOYo9o=.9389c806-77ed-49ea-91ab-5c4c01ffee77@github.com>

On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - do_thread(target) not self
>  - Remove checks for is_handshake_for, instead call Handshake::execute
>  - Switch order of handshake check

This bug/PR is specifically about this block of code:

  if (tlh == nullptr) {
    guarantee(Thread::is_JavaThread_protected_by_TLH(target),
              "missing ThreadsListHandle in calling context.");
    target->handshake_state()->add_operation(&op);

and the bug makes the claim that we need to adjust this
guarantee(). Okay, but this proposed fix is indirectly changing
the guarantee() by inserting this block of code before the
guarantee():

  if (target->is_handshake_safe_for(self)) {
    hs_cl->do_thread(target);
    return;
}

so we still have the original guarantee() that checks a
specific state with respect to ThreadsListHandles and
we replace it with a check, the `is_handshake_safe_for()`
call, that has nothing to do with ThreadsListHandles!

The original purpose of this logic block:

  if (tlh == nullptr) {
    guarantee(Thread::is_JavaThread_protected_by_TLH(target),
              "missing ThreadsListHandle in calling context.");
    target->handshake_state()->add_operation(&op);

is to require a protecting ThreadsListHandle to be in place
*somewhere* in the calling context since we have not
passed in a ThreadsListHandle from the calling context.

When I added the above block of code, I intentionally
updated all of the call sites that reached the new strict
check with ThreadsListHandles. This included calls sites
where the caller was the current thread. This was an
intentional change on my part to make sure that all the
JavaThreads being operated (including current) on are
protected by ThreadsListHandles.

When the Loom project was being developed, a number
of these carefully placed ThreadsListHandles were moved
and unprotected code paths were introduced. We believe
that these unprotected code paths are safe because we
believe that they are only used by the current thread and
the current thread does not really need a ThreadsListHandle.
That might be true, but it certainly complicates the reasoning
about the code paths.

The bug talks about adjusting the guarantee() to allow the
current thread to be unprotected by a ThreadsListHandle, but
the logic that we have switched to:

  // A JavaThread can always safely operate on it self and other threads
  // can do it safely if they are the active handshaker.
  bool is_handshake_safe_for(Thread* th) const {
    return _handshake.active_handshaker() == th || this == th;
  }

does more than that. It also allows the target to be unprotected
by a ThreadsListHandle if the calling thread is the active handshaker.
I'm not (yet) convinced that is a good policy.

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

Changes requested by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8992

From dcubed at openjdk.java.net  Mon Jun  6 20:37:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 6 Jun 2022 20:37:12 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
 <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
Message-ID: <wMNDxsKjKCaWNIolF5rf5tVIS0pR4PULQIxeDgdLw9o=.260af0a2-8981-4d82-9e05-918f9cfbe987@github.com>

On Mon, 6 Jun 2022 07:17:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - do_thread(target) not self
>>  - Remove checks for is_handshake_for, instead call Handshake::execute
>>  - Switch order of handshake check
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 401:
> 
>> 399:       Thread *current = Thread::current();
>> 400:       Handshake::execute(&op, thread);
>> 401:       guarantee(op.completed(), "Handshake failed. Target thread is not alive?");
> 
> I much prefer that the current-thread case is internalised by `Handshake::execute` now. The code creating the handshake op shouldn't have to worry about current thread or not.

Having `Handshake::execute()` handle the current-thread case will certainly
allow us to make the code consistent in all the callers of `Handshake::execute()`.

> src/hotspot/share/runtime/handshake.cpp line 357:
> 
>> 355:   if (target->is_handshake_safe_for(self)) {
>> 356:     hs_cl->do_thread(target);
>> 357:     return;
> 
> I like the idea of doing this, but I can't quite convince myself that it will always be safe when the target is not the current thread. ??

Because we're pushing the special case handling for current-thread down
into the three parameter version of `Handshake::execute()`, we'll also
directly execute the closure's `do_thread()` function in other calls to the
three parameter version of `Handshake::execute()` where we didn't change
the calling code site in this patch:

- src/hotspot/share/classfile/javaClasses.cpp: async_get_stack_trace()
- src/hotspot/share/prims/jvmtiExtensions.cpp: GetCarrierThread()
- src/hotspot/share/prims/whitebox.cpp: WB_HandshakeReadMonitors(), WB_HandshakeWalkStack()
- src/hotspot/share/runtime/handshake.cpp: execute(HandshakeClosure* hs_cl, JavaThread* target)
     Of course, since the two parameter version of `Handshake::execute()` is
     now a changed code path, that means that all callers to the two parameter
     version of `Handshake::execute()` are also affected. No, I'm not going to
     list all those call sites.

This is a change in behavior and I'm not saying that this is wrong, but it's
not clear to me that the repercussions are understood and discussed in
this PR.

What I'm mumbling about here might be the same thing that @dholmes-ora is
worried about, but I'm just being more verbose about it. :-)

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From dcubed at openjdk.java.net  Mon Jun  6 20:37:22 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 6 Jun 2022 20:37:22 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <gJZ-6xqk8k7a464QbqrDiH_viXGPUyZXRA84OpT9Rzc=.b231678d-1513-4bb3-ab8a-237182730471@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
 <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
 <gJZ-6xqk8k7a464QbqrDiH_viXGPUyZXRA84OpT9Rzc=.b231678d-1513-4bb3-ab8a-237182730471@github.com>
Message-ID: <fItSOahm1vpq6Q-s_bmpumfgj1ZvTzjpwoOGVnj47HE=.97723466-e744-4a52-b199-34354be36cce@github.com>

On Mon, 6 Jun 2022 07:20:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEventController.cpp line 370:
>> 
>>> 368:   }
>>> 369:   EnterInterpOnlyModeClosure hs;
>>> 370:   assert(state->get_thread() != NULL, "sanity check");
>> 
>> Existing: We have already performed this check. We set `target` above and returned if it was `NULL`.
>
> We also no longer need L358 as `current` is now unused.

JavaThread *target = state->get_thread();
  Thread *current = Thread::current();

  assert(state != NULL, "sanity check");

The `assert()` on L360 is in the wrong place. If `state == NULL`, we would
have crashed on L357 before we got to the assert(). This bug is pre-existing
and not due to this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From kvn at openjdk.java.net  Mon Jun  6 20:55:13 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 6 Jun 2022 20:55:13 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v4]
In-Reply-To: <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <Wa6Z_OECh1t0UXlc9qQ2A8M3LCevD6CXmEEbBG-_bws=.6b753a62-84e0-4fe6-8aee-094515a8a772@github.com>
Message-ID: <ynD_8P2Yeq8HM99CoMvaHG26jpkpxkCvkwImK0DCNZQ=.450d2c59-533f-48ed-89b4-3f3de0a8e914@github.com>

On Thu, 2 Jun 2022 17:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
>> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
>> The performance regression is due to auto-vectorization of small loops. 
>> We don?t have AVX3Threshold consideration in auto-vectorization. 
>> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
>> 
>> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
>> 
>> Please review.
>> 
>> Best Regard,
>> Sandhya
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment resolution

jbb2015 are only left in queue for performance testing. It may take time and I don't expect much variations in them.

Testing also include `MaxVectorSize=32` to compare with current changes. It shows slightly (1-3%) better results in some `Crypto-AESBench_decrypt/encrypt` sub-benchmarks but it could be due to variations we observed in them. On other hand `SuperWordMaxVectorSize=32` shows better results in some Renaissance  sub-benchmarks - actually it keep scores similar to current code and `MaxVectorSize=32` gives regression in them. Based on this I agree with current changes vs setting `MaxVectorSize=32`.

Both changes gives 4-5% improvement to `SPECjvm2008-MPEG`.

But I also observed 2.7% regression in `SPECjvm2008-SOR.small` with ParallelGC. For both types of changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From kvn at openjdk.java.net  Mon Jun  6 20:55:37 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 6 Jun 2022 20:55:37 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v5]
In-Reply-To: <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
Message-ID: <5JvDn6krvjUxP8adnjZ1FOgY5yclytav5qDzs9ZpJYI=.eb58cdc2-ce08-4d49-8a9c-a5a0669fab69@github.com>

On Mon, 6 Jun 2022 14:30:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
>> 
>> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
>> 
>> Brief tour of changes:
>>  - Check the incoming registers explicitly
>>  - Pass explicit argument registers to `fill_continuation_entry`
>>  - Use the usual `NativeCall` alignment code to produce a patchable call
>>  - Check that static stub is emitted, fail hard otherwise
>>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

I will look on it today.

Looks good. Do you plan similar change for Aarch64 code?

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

PR: https://git.openjdk.java.net/jdk/pull/8802Marked as reviewed by kvn (Reviewer).

From shade at openjdk.java.net  Mon Jun  6 20:55:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Jun 2022 20:55:40 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v5]
In-Reply-To: <5JvDn6krvjUxP8adnjZ1FOgY5yclytav5qDzs9ZpJYI=.eb58cdc2-ce08-4d49-8a9c-a5a0669fab69@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
 <5JvDn6krvjUxP8adnjZ1FOgY5yclytav5qDzs9ZpJYI=.eb58cdc2-ce08-4d49-8a9c-a5a0669fab69@github.com>
Message-ID: <wqr7Nb93840LDiezdPi9TCECPca0iGtoiT44jMXhGy8=.9e3925ff-cbe3-4f29-8251-c9ec4325135a@github.com>

On Mon, 6 Jun 2022 18:17:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks good. Do you plan similar change for Aarch64 code?

Yes, but not in JDK 19 timeframe. I want x86_64 code to be as clean as possible to serve as template for porting to other arches.

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From kvn at openjdk.java.net  Mon Jun  6 21:10:06 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 6 Jun 2022 21:10:06 GMT
Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v5]
In-Reply-To: <wqr7Nb93840LDiezdPi9TCECPca0iGtoiT44jMXhGy8=.9e3925ff-cbe3-4f29-8251-c9ec4325135a@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
 <BCoQ1zg_UQ5FNtV0VfBxKJJgf1nKV4AMO9KH5mM87mY=.c1464010-a416-4e44-bec3-ef69893e8cd6@github.com>
 <5JvDn6krvjUxP8adnjZ1FOgY5yclytav5qDzs9ZpJYI=.eb58cdc2-ce08-4d49-8a9c-a5a0669fab69@github.com>
 <wqr7Nb93840LDiezdPi9TCECPca0iGtoiT44jMXhGy8=.9e3925ff-cbe3-4f29-8251-c9ec4325135a@github.com>
Message-ID: <A4qJrF-2Hmp_2Bu9foXZvUw2Q1IYiNhdIB2NcYgvMnc=.1c656b1e-fc61-4c0a-8d6f-e07f252dfce4@github.com>

On Mon, 6 Jun 2022 18:20:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Looks good. Do you plan similar change for Aarch64 code?
> 
> Yes, but not in JDK 19 timeframe. I want x86_64 code to be as clean as possible to serve as template for porting to other arches.

Okay.

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From xgong at openjdk.java.net  Tue Jun  7 02:26:13 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 02:26:13 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
Message-ID: <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>

On Mon, 6 Jun 2022 10:40:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'jdk:master' into JDK-8283667
>>  - Use integer constant for offsetInRange all the way through
>>  - Rename "use_predicate" to "needs_predicate"
>>  - Rename the "usePred" to "offsetInRange"
>>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:
> 
>> 95:     public void byteLoadArrayMaskIOOBE() {
>> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
>> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);
> 
> For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.

Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue Jun  7 04:29:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 04:29:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v6]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Add constant OFFSET_IN_RANGE and OFFSET_OUT_OF_RANGE
 - Merge branch 'jdk:master' into JDK-8283667
 - Merge branch 'jdk:master' into JDK-8283667
 - Use integer constant for offsetInRange all the way through
 - Rename "use_predicate" to "needs_predicate"
 - Rename the "usePred" to "offsetInRange"
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

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

Changes: https://git.openjdk.java.net/jdk/pull/8035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=05
  Stats: 453 lines in 44 files changed: 174 ins; 21 del; 258 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue Jun  7 04:31:55 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 04:31:55 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <C-9nZ4OWaMHiiPyXSIo6ecFnlPLO1PYQLOBXENrkvqY=.942859a4-2e63-4ed2-8528-a7945c0d35bd@github.com>
Message-ID: <HTIV2NffqoJEA8scGT14YtTsLdvs4c85rEJxfDCMqNM=.64e56311-dfa8-4343-9e6c-37f15e19f617@github.com>

On Mon, 6 Jun 2022 15:41:06 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Looks good. As a follow on PR I think it would be useful to add constants `OFFSET_IN_RANGE` and `OFFSET_OUT_OF_RANGE`, then it becomes much clearer in source and you can drop the `/* offsetInRange */` comment on the argument.

Hi @PaulSandoz , thanks for the advice! I'v rebased the codes and added these two constants in the latest patch. Thanks again for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From duke at openjdk.java.net  Tue Jun  7 04:39:08 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 7 Jun 2022 04:39:08 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v2]
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <5PvYGuYNP9oMYb8F5RLWO7zRCihrxnIpZxLn7SantLc=.ad772b6f-03b7-4f17-9d30-50d06d575876@github.com>

> 8263377: Store method handle linkers in the 'non-nmethods' heap

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Remove dead codes
  
  remove unused argument of NativeJump::check_verified_entry_alignment
  remove unused argument of NativeJumip::patch_verified_entry
  remove dead codes in SharedRuntime::generate_method_handle_intrinsic_wrapper

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8760/files
  - new: https://git.openjdk.java.net/jdk/pull/8760/files/63771d64..00c99435

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8760&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8760&range=00-01

  Stats: 79 lines in 29 files changed: 3 ins; 33 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8760.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8760/head:pull/8760

PR: https://git.openjdk.java.net/jdk/pull/8760

From jbhateja at openjdk.java.net  Tue Jun  7 06:46:15 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 7 Jun 2022 06:46:15 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
 <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
Message-ID: <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>

On Tue, 7 Jun 2022 02:22:53 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java line 97:
>> 
>>> 95:     public void byteLoadArrayMaskIOOBE() {
>>> 96:         for (int i = 0; i < inSize; i += bspecies.length()) {
>>> 97:             VectorMask<Byte> mask = VectorMask.fromArray(bspecies, m, i);
>> 
>> For other case "if (offset >= 0 && offset <= (a.length - species.length())) )" we are anyways intrinsifying, should we limit this micro to work only for newly optimized case.
>
> Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.

It was just to remove the noise from a targeted micro benchmark. But we can keep it as it is.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue Jun  7 06:46:16 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 06:46:16 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v5]
In-Reply-To: <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <V0HBofdM9nf6LDyugIPx-8Mmfj4ttChw4lRi97qJzuk=.e887d85f-0235-4cc0-9e50-20c4edb09946@github.com>
 <Wgs5V3yDCVwQpUqGV0Pl9F9idn9u9Cprbjk0zx__zO0=.baf4afae-cfab-4bb1-b8a1-93b0215a2224@github.com>
 <fRSu6f8-3UQhTSh4thyyd_oArM9ccW3ASbdBAVjKgH4=.c284e308-2e74-4eda-8c23-0bba163c8ab1@github.com>
 <BEWMR9rnq3SWLMQxkU_pvOIxapWVHXfC-GC5fpZyepI=.e036cb56-bbbb-4a3f-b8cc-5124bc29fb31@github.com>
Message-ID: <rRZwR8URWPw-MKd8mFXM7lzGTj8K1uRywm6PwJuhsZA=.b9611a8f-66a3-4032-a6a6-9e8fb60ae7c5@github.com>

On Tue, 7 Jun 2022 06:41:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yeah, thanks and it's really a good suggestion to limit this benchmark only for the IOOBE cases. I locally modified the tests to make sure only the IOOBE case happens and the results show good as well. But do you think it's better to keep as it is since we can also see the performance of the common cases to make sure no regressions happen? As the current benchmarks can also show the performance gain by this PR.
>
> It was just to remove the noise from a targeted micro benchmark. But we can keep it as it is.

OK, thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From shade at openjdk.java.net  Tue Jun  7 06:58:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Jun 2022 06:58:28 GMT
Subject: Integrated: 8287071: Loom: Cleanup x86_64 gen_continuation_enter
In-Reply-To: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
References: <cvpEI3qwWVOurjeakg8--c5VKoVDPznERgwbejA6oVU=.b99e2a27-b30e-4389-94c0-74b319b2a899@github.com>
Message-ID: <KKQVUDeFoi3jrzTA2dMvt7cCsOvHhzkI3QTGK7gLMM4=.50fd2393-62c0-4d0b-b5a7-36471826559f@github.com>

On Fri, 20 May 2022 07:49:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures.
> 
> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient.
> 
> Brief tour of changes:
>  - Check the incoming registers explicitly
>  - Pass explicit argument registers to `fill_continuation_entry`
>  - Use the usual `NativeCall` alignment code to produce a patchable call
>  - Check that static stub is emitted, fail hard otherwise
>  - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator`
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom`

This pull request has now been integrated.

Changeset: 956d44d2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/956d44d2da54926a37acfb415d87f071663b4b40
Stats:     114 lines in 2 files changed: 51 ins; 18 del; 45 mod

8287071: Loom: Cleanup x86_64 gen_continuation_enter

Reviewed-by: rpressler, pchilanomate, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/8802

From shade at openjdk.java.net  Tue Jun  7 07:28:05 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Jun 2022 07:28:05 GMT
Subject: Integrated: 8286360: ARM32: Fix crashes after JDK-8284161 (Virtual
 Threads)
In-Reply-To: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
References: <eLotbKZNYf-OP4i_TUUTguT0-WvA4s1a4a-AcAeGBxg=.c432e165-c8d3-4432-bc55-528e7dcb8cd1@github.com>
Message-ID: <vQ98fHSTG05XpoZYCGYZPN3m2EZlXCEBawxqt1dTkgc=.b1d14f70-1198-4d12-940d-c32123a5ad6f@github.com>

On Tue, 10 May 2022 15:51:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Virtual Threads are not fully implemented on ARM32, but there is a fallback implementation that can be used. Still, there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the ARM32 code to the point that VM is able to build itself and pass tests. This adds the scaffolding for full implementation too.
> 
> Additional testing:
>  - [x] Linux arm32 fastdebug build
>  - [x] Linux arm32 fastdebug, `jdk_loom  hotspot_loom` pass
>  - [x] Linux arm32 fastdebug, `jdk_jfr` passes (some timeout failures, because the board I have is very slow)

This pull request has now been integrated.

Changeset: b6c6cc5d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6c6cc5d9918bf1727ae13d09f8a3bf677a058a7
Stats:     201 lines in 7 files changed: 140 ins; 38 del; 23 mod

8286360: ARM32: Fix crashes after JDK-8284161 (Virtual Threads)

Co-authored-by: Sergey Nazarkin <snazarki at openjdk.org>
Reviewed-by: dsamersoff

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

PR: https://git.openjdk.java.net/jdk/pull/8634

From jbhateja at openjdk.java.net  Tue Jun  7 07:42:20 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 7 Jun 2022 07:42:20 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v6]
In-Reply-To: <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <l6X4hVC2YiPB1RZH385njZVoD01lK8Kd0lusJqLmHIU=.9ac46aa1-c452-4a37-a7b9-e7bee40c0482@github.com>
Message-ID: <wgu9HcMaOkw21i79JHaHszJs92ECJZ7scMSC7UUKUOQ=.fc972169-ae4f-411d-8c1f-e0de0ed58fcb@github.com>

On Tue, 7 Jun 2022 04:29:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Add constant OFFSET_IN_RANGE and OFFSET_OUT_OF_RANGE
>  - Merge branch 'jdk:master' into JDK-8283667
>  - Merge branch 'jdk:master' into JDK-8283667
>  - Use integer constant for offsetInRange all the way through
>  - Rename "use_predicate" to "needs_predicate"
>  - Rename the "usePred" to "offsetInRange"
>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

LGTM.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue Jun  7 07:42:22 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 07:42:22 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <b2nHT9XvhX7tUfkcYAfuUjUHL2DG2VSpa9-H4FowQEw=.04925f22-9d62-49ab-9127-6b15d20ddcac@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> 
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

Thanks for the review @PaulSandoz  @sviswa7 @jatin-bhateja @merykitty ?

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue Jun  7 07:45:23 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 7 Jun 2022 07:45:23 GMT
Subject: Integrated: 8283667: [vectorapi] Vectorization for masked load with
 IOOBE with predicate feature
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <U6H5H5beZcLBNVGEKgaGRyVwQhDykSWyekdZbBIunt4=.fd6a7a40-4cd6-4eea-9e09-8601d66f25f5@github.com>

On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

This pull request has now been integrated.

Changeset: 39fa52b5
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/39fa52b5f7504eca7399b863b0fb934bdce37f7e
Stats:     453 lines in 44 files changed: 174 ins; 21 del; 258 mod

8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

Reviewed-by: sviswanathan, psandoz

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From chagedorn at openjdk.java.net  Tue Jun  7 07:52:59 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 7 Jun 2022 07:52:59 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v11]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <n1ZXoTCX1cIq8psTxCOs7ci7MqisUQGrQPZhbAs0F_4=.1a2ba165-2251-449d-83f4-0c7bf08bde8d@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:

 - Merge branch 'master' into JDK-8242181
 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - Apply remaining review comments from Thomas Stuefe
 - Change load_dwarf_file with DwarfFilePath and DebugInfo
 - ... and 56 more: https://git.openjdk.java.net/jdk/compare/42261d75...dbb687ef

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

Changes: https://git.openjdk.java.net/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=10
  Stats: 2784 lines in 18 files changed: 2687 ins; 41 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126

PR: https://git.openjdk.java.net/jdk/pull/7126

From duke at openjdk.java.net  Tue Jun  7 07:52:59 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 07:52:59 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v9]
In-Reply-To: <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
 <qzR7-THzprQvPm2icCX-LHOb68Y7M_r7HOMaDCuTWFo=.f452c2fd-9787-48ee-9823-4a10dbc66257@github.com>
 <yMt7s6pHlciJmkO9lVt6p2KCRLiU_4tP2MBwtGcBDUc=.fe56c895-a352-4318-a6e4-3f32a4da7ae6@github.com>
 <UUR3Xr8cHQMT1iC6sgEy5vOYj0Np7I_2_-yKC2_eNaQ=.e79645d9-d7e3-4e00-aca1-bc0beccbbbab@github.com>
 <REqNCKORi0CJSnixJ1fTYafdhKDziOItAIXe2u52Z2w=.7c455c20-f6c7-44e5-ae91-2f94d040249a@github.com>
Message-ID: <bvmH6vLxldXnXRSrxC2bS6XyX3zio9Cz4JK8fIMFBdQ=.62e319bc-4de5-4acc-9afb-e4e0deab0c1e@github.com>

On Thu, 2 Jun 2022 11:29:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>>> Thanks Thomas for doing the testing!
>> 
>> Hi Christian,
>> 
>> I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom.
>> 
>> I see test errors in TestDwarf on ppcle and x64, however. On x64:
>> 
>> 
>> ----------System.out:(52/5198)----------
>> Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_ho
 tspot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ]
>> [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490
>> [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490
>> Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log'
>> [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490
>> [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/c1_Compilation.cpp:616
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505
>> #  assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned
>> #
>> # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x73ca34]  Compilation::~Compilation()+0x84
>> #
>> # CreateCoredumpOnCrash turned off, no core file dumped
>> #
>> # An error report file with more information is saved as:
>> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log
>> [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo
>> [1.842s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.842s][info][dwarf] Failed to process the line number program correctly.
>> [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a
>> [1.843s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.843s][info][dwarf] Failed to process the line number program correctly.
>> [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011
>> [1.845s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.845s][info][dwarf] Failed to process the line number program correctly.
>> [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78
>> [1.849s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.849s][info][dwarf] Failed to process the line number program correctly.
>> [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3
>> [1.852s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.852s][info][dwarf] Failed to process the line number program correctly.
>> [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546
>> [1.855s][info][dwarf] Failed to parse the line number program header correctly.
>> [1.855s][info][dwarf] Failed to process the line number program correctly.
>> [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9
>> #
>> # Compiler replay data is saved as:
>> # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> hs_err_file: hs_err_pid44490.log
>> ----------System.err:(15/1242)----------
>> java.lang.RuntimeException: Could not find filename or line number in "V  [libjvm.so+0x74176a]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false
>> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
>> 	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
>> 	at TestDwarf.runAndCheck(TestDwarf.java:163)
>> 	at TestDwarf.test(TestDwarf.java:99)
>> 	at TestDwarf.main(TestDwarf.java:90)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:1585)
>
> After getting some more logs from @tstuefe, it turns out that they are using GCC 8 in the testing which emits the `.debug_line` section in DWARF 2 format which we do not allow and we bail out during parsing. This lets `TestDwarf` fail. 
> 
> The `.debug_line` section is already handled differently by the parser compared to the other sections. GCC 10 emits DWARF 3 for some reason (even though it should emit DWARF 4 as for the other sections) while GCC 11 emits DWARF 4. Therefore, the parser can handle both DWARF 3 and 4 for `.debug_line`. Having a look at the DWARF 2 spec, it turns out that we can reuse the code for parsing DWARF 3. This allows us to update the version bailout of `.debug_line` to allow DWARF 2 as valid version. I've tested this change by building HotSpot with GCC 8.2 and playing around with it.
> 
> In this process, I've also changed `TestDwarf.java` to skip all its tests if there was a bailout of the parser due to an unsupported DWARF format. I've added some more error logging.
> 
> I've also decided to get rid of UL as discussed before and replaced it by `tty` logging in combination with a new `TraceDwarfLevel` develop flag (for the different log levels).

@chhagedorn Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

PR: https://git.openjdk.java.net/jdk/pull/7126

From duke at openjdk.java.net  Tue Jun  7 09:58:11 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 7 Jun 2022 09:58:11 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v5]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <YJxA_5EmspGztjBWwNHQkBsAiAJDaX9w7GBCvwiNEX8=.cadc332b-c0c6-475f-82c5-28f7a1eb9205@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Passes tier1. Running tier2-5.

Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused variable
 - Use current instead of self as name for current thread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8992/files
  - new: https://git.openjdk.java.net/jdk/pull/8992/files/bf75d4c8..c476d300

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=03-04

  Stats: 10 lines in 2 files changed: 2 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8992/head:pull/8992

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Tue Jun  7 09:58:14 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 7 Jun 2022 09:58:14 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
 <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
Message-ID: <88BzZ6WLwkODQtklNT9aJRXVhZDE9YjJ5jpen6nxycM=.b648926e-5b36-4cbd-82e8-8610e0525897@github.com>

On Mon, 6 Jun 2022 07:15:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - do_thread(target) not self
>>  - Remove checks for is_handshake_for, instead call Handshake::execute
>>  - Switch order of handshake check
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 399:
> 
>> 397:       // so get current location with direct handshake.
>> 398:       GetCurrentLocationClosure op;
>> 399:       Thread *current = Thread::current();
> 
> This appears unused now.

Nice catch, thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From mbaesken at openjdk.java.net  Tue Jun  7 10:45:37 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 7 Jun 2022 10:45:37 GMT
Subject: RFR: JDK-8287735: Provide separate event category for dll operations
Message-ID: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>

Currently we have a number of event categories logged and displayed in the hs_err file like
Classes unloaded (0 events)
Classes redefined (0 events)
Internal exceptions (0 events)
VM Operations (0 events)
but the dll operations (like dll_load) go into the generic "Events" category where they usually are shifted out pretty fast.
Better provide a separate category DLL operations for them.
Currently the dll_load is logged.  Later dll_unload might be added.

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

Commit messages:
 - JDK-8287735

Changes: https://git.openjdk.java.net/jdk/pull/9058/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9058&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287735
  Stats: 27 lines in 6 files changed: 16 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9058.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9058/head:pull/9058

PR: https://git.openjdk.java.net/jdk/pull/9058

From duke at openjdk.java.net  Tue Jun  7 12:21:13 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 7 Jun 2022 12:21:13 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v5]
In-Reply-To: <YJxA_5EmspGztjBWwNHQkBsAiAJDaX9w7GBCvwiNEX8=.cadc332b-c0c6-475f-82c5-28f7a1eb9205@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <YJxA_5EmspGztjBWwNHQkBsAiAJDaX9w7GBCvwiNEX8=.cadc332b-c0c6-475f-82c5-28f7a1eb9205@github.com>
Message-ID: <eAE2WfcXdscBs0uTptNEskS2X6MMJXj0jnUDPLVu6Xc=.29c1d9cb-2b38-4662-ab85-3e43be21170e@github.com>

On Tue, 7 Jun 2022 09:58:11 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused variable
>  - Use current instead of self as name for current thread

It seems that we have at least two choices here:

1. Change the `is_handshake_safe_for` to `current == target` and be done with it.
2. Investigate whether `is_handshake_safe_for` is OK to be used in this context.

Is there anything I am missing?

I'm fine with going for option 1 but unless we need to get this change in quickly (it's a P3 bug, not sure what that entails) I'd like to wait for @robehn's input.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Tue Jun  7 12:42:05 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 7 Jun 2022 12:42:05 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v6]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Passes tier1. Running tier2-5.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Move assert up and remove other assert, remove unused var

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8992/files
  - new: https://git.openjdk.java.net/jdk/pull/8992/files/c476d300..f2646e04

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Tue Jun  7 12:42:06 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 7 Jun 2022 12:42:06 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v4]
In-Reply-To: <fItSOahm1vpq6Q-s_bmpumfgj1ZvTzjpwoOGVnj47HE=.97723466-e744-4a52-b199-34354be36cce@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <ixQXy2REZWXbaIqfS5xbKehDTlKoKnC5mCcN5gbVi-s=.34278e9c-f846-4c13-ad46-991f0a08de8a@github.com>
 <y-ljc9_r3ibRLQ85bq2oXeF8AXe2QrLMU8U7jG1AsHU=.3957762f-7a25-4173-afcd-e3ecc85a1b93@github.com>
 <gJZ-6xqk8k7a464QbqrDiH_viXGPUyZXRA84OpT9Rzc=.b231678d-1513-4bb3-ab8a-237182730471@github.com>
 <fItSOahm1vpq6Q-s_bmpumfgj1ZvTzjpwoOGVnj47HE=.97723466-e744-4a52-b199-34354be36cce@github.com>
Message-ID: <B0EOF3M1eGICC0TULduGLTYPBDPLs2Boh36eyiQ7CvA=.89060b0f-8075-48ce-8933-5fe04cb42129@github.com>

On Mon, 6 Jun 2022 16:36:01 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> We also no longer need L358 as `current` is now unused.
>
> JavaThread *target = state->get_thread();
>   Thread *current = Thread::current();
> 
>   assert(state != NULL, "sanity check");
> 
> The `assert()` on L360 is in the wrong place. If `state == NULL`, we would
> have crashed on L357 before we got to the assert(). This bug is pre-existing
> and not due to this PR.

Removed unused variable, moved the `state != NULL` assert up and removed the `state->get_thread() != NULL` assert as it's unnecessary.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From mcimadamore at openjdk.java.net  Tue Jun  7 13:00:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Jun 2022 13:00:37 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8d28734e...5b8f7246

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

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=01
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From dholmes at openjdk.java.net  Tue Jun  7 13:34:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 7 Jun 2022 13:34:59 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v6]
In-Reply-To: <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
Message-ID: <xgjKovBTFI3rQsPFNs-yXTbS60JmggMLy_oFnk8CpNM=.e10fb3c0-135b-482c-abf4-1bb6576f14b8@github.com>

On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert up and remove other assert, remove unused var

I have to agree with Dan. This is supposed to only be about targeting the current thread, but we are now no longer ensuring the target is protected by a TLH when the current thread is the active_handshaker. So I would vote for:

1. Change the is_handshake_safe_for to current == target and be done with it.

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

PR: https://git.openjdk.java.net/jdk/pull/8992

From duke at openjdk.java.net  Tue Jun  7 14:21:05 2022
From: duke at openjdk.java.net (olivergillespie)
Date: Tue, 7 Jun 2022 14:21:05 GMT
Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs
In-Reply-To: <NdBcEFVy7aJ6VidmqGuXTMy9qUchpGGHBno8ZCkQUbA=.e87b4ce8-b0de-4a02-805c-dc14a21d27ea@github.com>
References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com>
 <NKq0VzAenxsK3zecPlM4VWDs9Fvx5XHO2h7apv4ZagQ=.23d5bb3a-8d06-462b-bcf2-7e7dff22617a@github.com>
 <NdBcEFVy7aJ6VidmqGuXTMy9qUchpGGHBno8ZCkQUbA=.e87b4ce8-b0de-4a02-805c-dc14a21d27ea@github.com>
Message-ID: <fc14d8dU00KbKlXp6wpY6dfOhhfzmMx75PXy70oOLNM=.a6c937a5-87a7-4d77-8029-c6ba3ceac1a7@github.com>

On Wed, 1 Jun 2022 23:42:17 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Thanks for all the help so far. Is there anything I can help with?
>
> @olivergillespie In our analysis of mpegaudio, we found that the problem was due to auto-vectorizer kicking in for small array initialization. The auto-vectorization does not take into consideration AVX3Threshold. I have submitted a simple PR to answer your concerns https://github.com/openjdk/jdk/pull/8877. Please take a look. The PR limits the auto-vectorizer to 256-bit or 32-byte for Cascade Lake.

Thanks @sviswa7 ! I don't have the expertise to evaluate your auto-vectorizer change from a theoretical standpoint. I'd like to test it out in my real applications to see if the issue you found in mpegaudio is the same issue I see on a more complex app, but unfortunately I won't be able to do that quickly (not easy to swap out JDK versions in those apps).

I'm still of the opinion that AVX3 on Cascade Lake in the JVM seems more dangerous than it's worth across the board, due to the documented inherent downclocking behaviour of that architecture. Various other SPECjvm benchmarks consistently downclock by >15%, so even if they don't show a direct performance regression with AVX3 (the improved AVX3 performance roughly balances the downclocking), they have a negative impact on other code running on the host.

It's possible your tighter change covers most of the cases in practice, which would be great, but I think this broader change still makes sense conceptually.

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

PR: https://git.openjdk.java.net/jdk/pull/8731

From bulasevich at openjdk.java.net  Tue Jun  7 15:49:23 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 7 Jun 2022 15:49:23 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
Message-ID: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>

The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.

Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.

The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.

Example. Dummy method disassembly on AARCH, before vs after:

[Verified Entry Point]                          |  [Verified Entry Point]
  78c63b80:   nop                               |    7437e480:   nop
  78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
  78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
  78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
  78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
  78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
  78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
  78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
  78c63ba0:   .inst   0x00000000 ; undefined    |
  78c63ba4:   .inst   0x00000000 ; undefined    |
  78c63ba8:   .inst   0x00000000 ; undefined    |
  78c63bac:   .inst   0x00000000 ; undefined    |
  78c63bb0:   .inst   0x00000000 ; undefined    |
  78c63bb4:   .inst   0x00000000 ; undefined    |
  78c63bb8:   .inst   0x00000000 ; undefined    |
  78c63bbc:   .inst   0x00000000 ; undefined    |
[Stub Code]                                     |  [Stub Code]
  78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
  78c63bc4:   br      x8                        |    7437e4a4:   br      x8
  78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
  78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
[Exception Handler]                             |  [Exception Handler]
  78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
[Deopt Handler Code]                            |  [Deopt Handler Code]
  78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
  78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
  78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

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

Commit messages:
 - fixing the CodeBuffer overflow assert on x86 build: SharedRuntime::generate_handler_blob asks a 1KB buffer,
 - rollback InteriorEntryAlignment change
 - jtreg/compiler tests update
 - Undo CodeEntryAlignment modification. Each code section (constants,code,stubs) have got its own alignment
 - use InteriorEntryAlignment for code sections

Changes: https://git.openjdk.java.net/jdk/pull/8453/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287373
  Stats: 60 lines in 9 files changed: 28 ins; 3 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8453.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8453/head:pull/8453

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Tue Jun  7 15:49:24 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 7 Jun 2022 15:49:24 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <yfcRX9IqPYcHa6eMZSSqzN7fgLSoG8RjoD491nQ7B7M=.01be737d-f692-463a-92e2-cfb711e596e2@github.com>

On Thu, 28 Apr 2022 14:46:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

src/hotspot/cpu/aarch64/globals_aarch64.hpp line 40:

> 38: 
> 39: define_pd_global(uintx, CodeCacheSegmentSize,    64 COMPILER1_AND_COMPILER2_PRESENT(+64)); // Tiered compilation has large code-entry alignment.
> 40: define_pd_global(intx, CodeEntryAlignment,       64);

This change looks reasonable to me. I found the following in the N1 Opt Guide:

Consider aligning subroutine entry points and branch targets to 32B boundaries, within the bounds of the code-density requirements of the program. This will ensure that the subsequent fetch can maximize bandwidth following the taken branch by bringing in all useful instructions

src/hotspot/share/asm/codeBuffer.hpp line 259:

> 257:     // TODO: move InteriorEntryAlignment to common c1/c2 header
> 258:     int code_entry_aliginment = (int) COMPILER2_PRESENT(InteriorEntryAlignment) NOT_COMPILER2(CodeEntryAlignment);
> 259:     return MAX2((int)sizeof(jdouble), code_entry_aliginment);

I don't think the stub code section needs alignment more than 4 bytes. It is not performance critical code.

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From kvn at openjdk.java.net  Tue Jun  7 15:52:23 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 15:52:23 GMT
Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs
In-Reply-To: <fc14d8dU00KbKlXp6wpY6dfOhhfzmMx75PXy70oOLNM=.a6c937a5-87a7-4d77-8029-c6ba3ceac1a7@github.com>
References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com>
 <NKq0VzAenxsK3zecPlM4VWDs9Fvx5XHO2h7apv4ZagQ=.23d5bb3a-8d06-462b-bcf2-7e7dff22617a@github.com>
 <NdBcEFVy7aJ6VidmqGuXTMy9qUchpGGHBno8ZCkQUbA=.e87b4ce8-b0de-4a02-805c-dc14a21d27ea@github.com>
 <fc14d8dU00KbKlXp6wpY6dfOhhfzmMx75PXy70oOLNM=.a6c937a5-87a7-4d77-8029-c6ba3ceac1a7@github.com>
Message-ID: <N-hlygGEyup1FAJIJSVbzASgOz_WiYnEr57OyZcTSnA=.6f32f092-0b0b-4b4a-a425-3af449918384@github.com>

On Tue, 7 Jun 2022 14:17:37 GMT, olivergillespie <duke at openjdk.java.net> wrote:

>> @olivergillespie In our analysis of mpegaudio, we found that the problem was due to auto-vectorizer kicking in for small array initialization. The auto-vectorization does not take into consideration AVX3Threshold. I have submitted a simple PR to answer your concerns https://github.com/openjdk/jdk/pull/8877. Please take a look. The PR limits the auto-vectorizer to 256-bit or 32-byte for Cascade Lake.
>
> Thanks @sviswa7 ! I don't have the expertise to evaluate your auto-vectorizer change from a theoretical standpoint. I'd like to test it out in my real applications to see if the issue you found in mpegaudio is the same issue I see on a more complex app, but unfortunately I won't be able to do that quickly (not easy to swap out JDK versions in those apps).
> 
> I'm still of the opinion that AVX3 on Cascade Lake in the JVM seems more dangerous than it's worth across the board, due to the documented inherent downclocking behaviour of that architecture. Various other SPECjvm benchmarks consistently downclock by >15%, so even if they don't show a direct performance regression with AVX3 (the improved AVX3 performance roughly balances the downclocking), they have a negative impact on other code running on the host.
> 
> It's possible your tighter change covers most of the cases in practice, which would be great, but I think this broader change still makes sense conceptually.

@olivergillespie you can test you application with `-XX:MaxVectorSize=32` product flag to see effects of #8877 changes.
Main concern about changing AVX is reduction of instructions set which could be useful.

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

PR: https://git.openjdk.java.net/jdk/pull/8731

From ngasson at openjdk.java.net  Tue Jun  7 16:51:29 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 7 Jun 2022 16:51:29 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
Message-ID: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>

The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.

Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

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

Commit messages:
 - 8287325: AArch64: fix virtual threads with -XX:UseBranchProtection=pac-ret

Changes: https://git.openjdk.java.net/jdk/pull/9067/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287325
  Stats: 80 lines in 16 files changed: 61 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9067.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9067/head:pull/9067

PR: https://git.openjdk.java.net/jdk/pull/9067

From duke at openjdk.java.net  Tue Jun  7 17:19:45 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 7 Jun 2022 17:19:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compare method in Integer and Long
Message-ID: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>

Hi,

This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .

Thank you very much.

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

Commit messages:
 - format
 - compare unsigned

Changes: https://git.openjdk.java.net/jdk/pull/9068/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283726
  Stats: 235 lines in 13 files changed: 224 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9068.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9068/head:pull/9068

PR: https://git.openjdk.java.net/jdk/pull/9068

From mark.reinhold at oracle.com  Tue Jun  7 17:31:08 2022
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 07 Jun 2022 10:31:08 -0700
Subject: Obsoleting JavaCritical
In-Reply-To: <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
 <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
Message-ID: <20220607103108.900830823@eggemoggin.niobe.net>

2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>> CLOCK_REALTIME.
> 
> Unfortunately System.currentTimeMillis() offers only millisecond
> granularity which is the reason why our industry has to resort to
> clock_gettime.

If the platform included, say, an intrinsified System.nanoRealTime()
method that returned clock_gettime(CLOCK_REALTIME), how much would
that help developers in your unnamed industry?

In a similar vein, if people are finding it necessary to ?replace parts
of NIO with hand-crafted native code? then it would be interesting to
understand what their requirements are.  Some simple enhancements to
the NIO API would be much less costly to design and implement than a
generalized user-level native-call intrinsification mechanism.

- Mark

From kvn at openjdk.java.net  Tue Jun  7 17:33:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 17:33:08 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>

On Thu, 28 Apr 2022 14:46:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

Why you changed tested alignment to 8 for JVMCI tests?

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 2635:

> 2633:   // allocate space for the code
> 2634:   // setup code generation tools
> 2635:   CodeBuffer   buffer("handler_blob", 2048, 1024);

Why you need to double the size?

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 667:

> 665:   int total_size = align_up(_constants_size, CodeSection::alignment(CodeBuffer::SECT_INSTS)) +
> 666:                    align_up(_code_size, CodeSection::alignment(CodeBuffer::SECT_STUBS)) +
> 667:                    stubs_size;

At first look it is messed up. I understand that you are trying to take into account space between sections. It assumed the order of sections. 
Add comment.

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Tue Jun  7 18:14:16 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 7 Jun 2022 18:14:16 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <bni8Ad8byY21oNHbsk5auF7KI3g_h31q8llyaF0i2Ro=.8b7d3627-94c0-4a10-a630-e4029bed5100@github.com>

On Thu, 28 Apr 2022 14:46:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

src/hotspot/share/asm/codeBuffer.cpp line 100:

> 98: void CodeBuffer::initialize(csize_t code_size, csize_t locs_size) {
> 99:   // Compute maximal alignment.
> 100:   int align = _consts.alignment() + _insts.alignment() + _stubs.alignment();

I suggest to clean this up by introducing a variable:

int total_size = code_size + _consts.alignment() + _insts.alignment() + _stubs.alignment() + 3 * slop;

You explicitly list all three sections. So you have disconnected `SEC_LIMIT`. Or you can add an assert checking that `SEC_LIMIT` is 3.

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From kvn at openjdk.java.net  Tue Jun  7 18:14:19 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 18:14:19 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Please add microbenchmark and show its results.

src/hotspot/share/opto/subnode.hpp line 217:

> 215: //------------------------------CmpU3Node--------------------------------------
> 216: // Compare 2 unsigned values, returning integer value (-1, 0 or 1).
> 217: class CmpU3Node : public CmpUNode {

Place it after `CmpUNode` class.

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

PR: https://git.openjdk.java.net/jdk/pull/9068

From coleenp at openjdk.java.net  Tue Jun  7 18:23:39 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 7 Jun 2022 18:23:39 GMT
Subject: RFR: JDK-8287735: Provide separate event category for dll
 operations
In-Reply-To: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
References: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
Message-ID: <UPzI6RmeFgXP1HGoyacAku-WJZKYcX3ML8XCZ5aKx1U=.5915037e-8421-48bd-b352-8ef1e5a2c49a@github.com>

On Tue, 7 Jun 2022 10:36:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have a number of event categories logged and displayed in the hs_err file like
> Classes unloaded (0 events)
> Classes redefined (0 events)
> Internal exceptions (0 events)
> VM Operations (0 events)
> but the dll operations (like dll_load) go into the generic "Events" category where they usually are shifted out pretty fast.
> Better provide a separate category DLL operations for them.
> Currently the dll_load is logged.  Later dll_unload might be added.

Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9058

From kvn at openjdk.java.net  Tue Jun  7 19:06:33 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 19:06:33 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
Message-ID: <Gr8S9EhDipTwTnKZxzTSRCO19IHKK5g_SLOzg6rcqq0=.69ddd93b-e8d2-41f9-9e63-89174cb3a240@github.com>

On Wed, 1 Jun 2022 11:59:36 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove superfluous if stmt

Consider moving this code into separate method.
This part of code is used for processing only uncommon traps when compiled code traps.
A compiled method could be deoptimized for other reasons too. Both paths calls  `fetch_unroll_info_helper()`. May be it is better place to print and log (an other RFE).

src/hotspot/share/runtime/deoptimization.cpp line 1937:

> 1935:       char* name_sig = tm->name_and_sig_as_C_string();
> 1936:       const char* reason_name = Deoptimization::trap_reason_name(reason);
> 1937:       const char* reason_action = Deoptimization::trap_action_name(action);

What is the reason to specify `Deoptimization::` in these calls?

src/hotspot/share/runtime/deoptimization.cpp line 1941:

> 1939:       log_debug(deoptimization)("cid: %d osr: %s level: %d %s @ %d %s -> %s",
> 1940:                                 nm->compile_id(),
> 1941:                                 (nm->is_osr_method() ? "true" : "false"),

Since it is one-liner it should follow how we print for `-Xlog:jit+compilation=debug`: 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileTask.cpp#L482

[0.142s][debug][jit,compilation]    6 %     4       Reproducer::run @ 8 (39 bytes)

Of cause we can use `osr` instead of `%` in output to be clear.

You can simplify `osr: %s` print by `%s` and `(nm->is_osr_method() ? "osr" : "   ")`
You also need to print `osr_bci` - we can have separate compilations of the same method for different `bci`.
Also print `p2i(fr.pc())` and relative PC which very useful:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1883

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From rpressler at openjdk.java.net  Tue Jun  7 19:16:36 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Tue, 7 Jun 2022 19:16:36 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <jnu1Gt75GpqVV_4bOE3IZ5B6WaKKBJ0JwvC2tXzcH5w=.a75adfc2-0eb3-40db-9e98-f11b97c515c4@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

Could you explain what it is that this change attempts to do? Does _every_ frame's returns address need to be patched on both freeze and thaw? If so, the slow path always has to be taken as we don't walk frames on the fast path. That slows down virtual threads by ~5-20x.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From stuefe at openjdk.java.net  Tue Jun  7 19:27:46 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Jun 2022 19:27:46 GMT
Subject: RFR: JDK-8287735: Provide separate event category for dll
 operations
In-Reply-To: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
References: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
Message-ID: <6P7bQ4car7DuWHhoP26-eTu0EzuaAhXrVsuPg5qTNxI=.c606843a-3c1c-4e95-8753-153573446034@github.com>

On Tue, 7 Jun 2022 10:36:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have a number of event categories logged and displayed in the hs_err file like
> Classes unloaded (0 events)
> Classes redefined (0 events)
> Internal exceptions (0 events)
> VM Operations (0 events)
> but the dll operations (like dll_load) go into the generic "Events" category where they usually are shifted out pretty fast.
> Better provide a separate category DLL operations for them.
> Currently the dll_load is logged.  Later dll_unload might be added.

Looks good.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9058

From rpressler at openjdk.java.net  Tue Jun  7 20:10:31 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Tue, 7 Jun 2022 20:10:31 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <zkNFgl9WHVxYzbURlWf2IvEugff1YYugBN65FiE8DZ8=.51abdc03-e03f-4898-a7a1-4bee0474c4f9@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

If this feature requires re-signing every frame, then PAC-RET should be reconsidered for Java frames (though not native frames). In that case, the right fix for JDK 19 would be to disable this mode when preview is enabled. BTW, +PreserveFramePointer also causes a huge slowdown for virtual threads as it requires the slow path to be taken on every thaw.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From aph at openjdk.java.net  Tue Jun  7 20:10:32 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 7 Jun 2022 20:10:32 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <zkNFgl9WHVxYzbURlWf2IvEugff1YYugBN65FiE8DZ8=.51abdc03-e03f-4898-a7a1-4bee0474c4f9@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
 <zkNFgl9WHVxYzbURlWf2IvEugff1YYugBN65FiE8DZ8=.51abdc03-e03f-4898-a7a1-4bee0474c4f9@github.com>
Message-ID: <8OOwbsVEn0qshXs66fTy5qRzpqJlnY5-rL_RGlyVC6c=.fce26e55-e7f2-4a7a-8038-bd8e2e45d8b3@github.com>

On Tue, 7 Jun 2022 20:04:40 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> If this feature requires re-signing every frame, then PAC-RET should be reconsidered for Java frames (though not native frames). In that case, the right fix for JDK 19 would be to disable this mode when preview is enabled. BTW, +PreserveFramePointer also causes a huge slowdown for virtual threads as it requires the slow path to be taken on every thaw.

I agree. For the preview, I think we can do without  -XX:UseBranchProtection=pac-ret. We should take some time to think about the best way to approach pac-ret with virtual threads.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From bulasevich at openjdk.java.net  Tue Jun  7 20:44:32 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 7 Jun 2022 20:44:32 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>
Message-ID: <IdZ1iIDNJdLxxK3TS3miGqxkqvqbS5RKOSJQZJOmwe4=.4805079a-fedb-4e8e-b89a-027acbad0167@github.com>

On Tue, 7 Jun 2022 16:11:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
>> 
>> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
>> 
>> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
>> 
>> Example. Dummy method disassembly on AARCH, before vs after:
>> 
>> [Verified Entry Point]                          |  [Verified Entry Point]
>>   78c63b80:   nop                               |    7437e480:   nop
>>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>>   78c63ba0:   .inst   0x00000000 ; undefined    |
>>   78c63ba4:   .inst   0x00000000 ; undefined    |
>>   78c63ba8:   .inst   0x00000000 ; undefined    |
>>   78c63bac:   .inst   0x00000000 ; undefined    |
>>   78c63bb0:   .inst   0x00000000 ; undefined    |
>>   78c63bb4:   .inst   0x00000000 ; undefined    |
>>   78c63bb8:   .inst   0x00000000 ; undefined    |
>>   78c63bbc:   .inst   0x00000000 ; undefined    |
>> [Stub Code]                                     |  [Stub Code]
>>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
>> [Exception Handler]                             |  [Exception Handler]
>>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
>> [Deopt Handler Code]                            |  [Deopt Handler Code]
>>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined
>
> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 2635:
> 
>> 2633:   // allocate space for the code
>> 2634:   // setup code generation tools
>> 2635:   CodeBuffer   buffer("handler_blob", 2048, 1024);
> 
> Why you need to double the size?

I did it to fix the CodeBuffer overflow assert on x86 build. SharedRuntime::generate_handler_blob asks a 1KB buffer -
actually CodeBuffer::initialize reserves the given size with some extra bytes; with the new formula (code_size + align + slop * SECT_LIMIT) the extra bytes number is reduced, causing the handler_blob generator buffer to overflow. My solution is to double the code_size estimate for handler_blob generator buffer. The same 2048/1024 numbers we can see on other platforms - aarch, pcc, amd, riscv.

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From kvn at openjdk.java.net  Tue Jun  7 20:57:28 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 20:57:28 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <IdZ1iIDNJdLxxK3TS3miGqxkqvqbS5RKOSJQZJOmwe4=.4805079a-fedb-4e8e-b89a-027acbad0167@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>
 <IdZ1iIDNJdLxxK3TS3miGqxkqvqbS5RKOSJQZJOmwe4=.4805079a-fedb-4e8e-b89a-027acbad0167@github.com>
Message-ID: <TKlTnfMAa002PR7pnYuw3xGeARD0pPARblm0Zx9rT2o=.caa177a1-4fc6-4072-a188-f88e3c1c860d@github.com>

On Tue, 7 Jun 2022 20:41:04 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 2635:
>> 
>>> 2633:   // allocate space for the code
>>> 2634:   // setup code generation tools
>>> 2635:   CodeBuffer   buffer("handler_blob", 2048, 1024);
>> 
>> Why you need to double the size?
>
> I did it to fix the CodeBuffer overflow assert on x86 build. SharedRuntime::generate_handler_blob asks a 1KB buffer -
> actually CodeBuffer::initialize reserves the given size with some extra bytes; with the new formula (code_size + align + slop * SECT_LIMIT) the extra bytes number is reduced, causing the handler_blob generator buffer to overflow. My solution is to double the code_size estimate for handler_blob generator buffer. The same 2048/1024 numbers we can see on other platforms - aarch, pcc, amd, riscv.

okay

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Tue Jun  7 21:22:39 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 7 Jun 2022 21:22:39 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <F0Wc_MyttnViU9WIZ04gWoii-mCpWaDyGfoWyAV0slY=.d9c0e4cd-4a8a-414c-9ff5-5cb6db0736e1@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <F0Wc_MyttnViU9WIZ04gWoii-mCpWaDyGfoWyAV0slY=.d9c0e4cd-4a8a-414c-9ff5-5cb6db0736e1@github.com>
Message-ID: <OF3lsXKK5sEaETekHJ75EpY3qRqvOGRmzktH7JyTJmE=.6442c2de-3531-4bf3-9139-168f00d396a7@github.com>

On Sat, 4 Jun 2022 01:43:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> if it wouldn't be better to use a subclass of CompiledMethod

An earlier [commit](https://github.com/openjdk/jdk/compare/994f2e92...yftsai:127609e3) tried the idea. It implemented many functions that are irrelevant to MH intrinsics.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From bulasevich at openjdk.java.net  Tue Jun  7 21:32:38 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 7 Jun 2022 21:32:38 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <LkXNhbuvPkSX4ZDE_zTxLNi4OfhBEXu1nINdMydM4I8=.fe0c923a-414a-4cad-8532-3ec2f70c56f7@github.com>
Message-ID: <-FmVJuWGo_EEBCrqdS1lsCBwxAOe3RQoi480GRYGVzM=.3d765e12-8b4a-4f73-9b05-41f9a98bfdc6@github.com>

On Tue, 7 Jun 2022 17:29:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Why you changed tested alignment to 8 for JVMCI tests?

HotSpotCompiledCode.dataSectionAlignment value was changed to 8 to correspond the new CodeBuffer.constants code section alignment.

The jtreg tests issue was repoduced as "invalid data section alignment" JVMCI error in [CodeInstaller::initialize_fields](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp#L598)

> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 667:
> 
>> 665:   int total_size = align_up(_constants_size, CodeSection::alignment(CodeBuffer::SECT_INSTS)) +
>> 666:                    align_up(_code_size, CodeSection::alignment(CodeBuffer::SECT_STUBS)) +
>> 667:                    stubs_size;
> 
> At first look it is messed up. I understand that you are trying to take into account space between sections. It assumed the order of sections. 
> Add comment.

Ok. Thank you

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Tue Jun  7 21:49:30 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 7 Jun 2022 21:49:30 GMT
Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <0KgYWC5E2rQtzowy4oxLsQE71M7Q6X42WGX5lO1Bok4=.8111f52e-4afb-41b3-bf59-331cf839db6d@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

Vladimir(@vnkozlov) and Andrew(@theRealAph), could you please have a look?

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From kvn at openjdk.java.net  Tue Jun  7 22:25:33 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 22:25:33 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <yM94XeIUXEAdBzl_le852snfLAnMP_OhWayHaPGyNqU=.f787e462-daab-4538-95be-7b20be83c697@github.com>

On Thu, 28 Apr 2022 14:46:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

test/hotspot/jtreg/compiler/jvmci/errors/TestInvalidCompilationResult.java line 88:

> 86:     }
> 87: 
> 88:     static final int validDataSectionAlignment = 8;

Add comment to explain where 8 comes from.

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Tue Jun  7 23:25:34 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 7 Jun 2022 23:25:34 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap
In-Reply-To: <FPizopcQv2dW0kARitd4brTB5vORQlE9qLwQ-n_FuAE=.ea568fab-177d-4c91-96b8-691bb318a8d8@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <FPizopcQv2dW0kARitd4brTB5vORQlE9qLwQ-n_FuAE=.ea568fab-177d-4c91-96b8-691bb318a8d8@github.com>
Message-ID: <e12P5N37cHgHpfh6Q45H0ha1YIE5tKoD_3aEQOJ10EI=.5fefc4df-a07e-4c9f-b592-5e8046d810fc@github.com>

On Sat, 4 Jun 2022 01:23:58 GMT, Dean Long <dlong at openjdk.org> wrote:

> Can't we use the existing AdapterBlob or MethodHandlesAdapterBlob?

An MH intrinsic is handled differently from them in SharedRuntime::continuation_for_implicit_exception and compiledIC.
The extra field _method is used in places like trace_exception unless this information is not important.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From kvn at openjdk.java.net  Tue Jun  7 23:26:35 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 23:26:35 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
 <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>
 <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>
Message-ID: <DPBOSeqsfvw9AmqO7if7Mv0IO7MvzdtdJcIWunSIz98=.ea6fb39e-688c-4a4b-9956-9d8a5e432177@github.com>

On Thu, 2 Jun 2022 17:44:54 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>>> Hi @sviswa7 , #7806 implemented an interface for auto-vectorization to disable some unprofitable cases on aarch64. Can it also be applied to your case?
>> 
>> Maybe. But it would require more careful changes. And that changeset is not integrated yet.
>> Current changes are clean and serve their purpose good.
>> 
>> And, as Jatin and Sandhya said, we may do proper fix after JDK 19 fork. Then we can look on your proposal.
>
> @vnkozlov @jatin-bhateja Your review comments are implemented. Please take a look.

@sviswa7, please, file separate RFE for SPECjvm2008-SOR.small issue (different unrolling factor).

I got all performance data from our and yours data and I think these change are ready for integration. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From duke at openjdk.java.net  Tue Jun  7 23:45:14 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 7 Jun 2022 23:45:14 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during code
 emission
Message-ID: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>

Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.

As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.

I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.

**I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.

Thanks in advance,
Cesar

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

Commit messages:
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - merging
 - merge fix for macos building
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/239ac2a5...7c739f77

Changes: https://git.openjdk.java.net/jdk/pull/9074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8241503
  Stats: 2393 lines in 49 files changed: 117 ins; 332 del; 1944 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9074/head:pull/9074

PR: https://git.openjdk.java.net/jdk/pull/9074

From kvn at openjdk.java.net  Tue Jun  7 23:48:36 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 23:48:36 GMT
Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <JQR5nB5Nq_qUnypeux81hKt8TwkKar1CBshPuivPRgs=.a00f628f-7c79-45bd-8e13-f2f5e70c2f0f@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

@bulasevich reviewed original #8024 PR. He should look on this too.

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From duke at openjdk.java.net  Tue Jun  7 23:48:36 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 7 Jun 2022 23:48:36 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v2]
In-Reply-To: <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
Message-ID: <tEhHEklmFS1hcl5K4gc2wKQZy_i6qUHa4A29MbkIPEY=.b20fbd82-b578-49dc-b674-057fdbfc652a@github.com>

On Fri, 3 Jun 2022 17:42:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove dead codes
>>   
>>   remove unused argument of NativeJump::check_verified_entry_alignment
>>   remove unused argument of NativeJumip::patch_verified_entry
>>   remove dead codes in SharedRuntime::generate_method_handle_intrinsic_wrapper
>
> src/hotspot/share/ci/ciMethod.cpp line 1131:
> 
>> 1129:                      CompiledMethod* cm = (code == nullptr) ? nullptr : code->as_compiled_method_or_null();
>> 1130:                      if (cm != NULL && (cm->comp_level() == CompLevel_full_optimization)) {
>> 1131:                        _instructions_size = cm->insts_end() - cm->verified_entry_point();
> 
> So, the old code only used sets _instruction_size if `comp_level` is `CompLevel_full_optimization`. Since the old shared runtime code used `new_native_nmethod`, which ends up setting comp_level to `CompLevel_none`, this branch is also not being taken in the current code?
> 
> In that case, this looks good.

Correct, comp_level of MH intrinsics were set to `CompLevel_none`.

> src/hotspot/share/code/codeBlob.cpp line 354:
> 
>> 352:   if (mhi != NULL) {
>> 353:     debug_only(mhi->verify();) // might block
>> 354:   }
> 
> This is debug only. Looking at CodeCache::allocate, it can only return `NULL` if the allocation size is `<= 0`, in which case an earlier assert will already fire. So, this null check doesn't seem needed?
> Suggestion:
> 
>   debug_only(mhi->verify();) // might block

This seems needed. CodeCache::allocate may return `NULL` if the code cache is full.

> src/hotspot/share/code/codeBlob.cpp line 360:
> 
>> 358: void MethodHandleIntrinsicBlob::verify() {
>> 359:   // Make sure all the entry points are correctly aligned for patching.
>> 360:   NativeJump::check_verified_entry_alignment(code_begin(), code_begin());
> 
> This method only seems implemented on x86, which ignores the first argument. Maybe it's a good opportunity to clean up the first argument?

Sure. Same for NativeJump::patch_verified_entry.

> src/hotspot/share/compiler/compileBroker.hpp line 307:
> 
>> 305:                                  TRAPS);
>> 306: 
>> 307:   static CodeBlob* compile_method(const methodHandle& method,
> 
> Not so sure about these changes. It seems to me that if a method is requested to be compiled, it should always result in an nmethod.
> 
> Alternatively, would it be possible to keep these functions returning an `nmethod` but add an assert at the start to check that the passed `method` is not a method handle intrinsic?

The implementation assumed that MH intrinsics are possible input. Once the assertion is added, two conditions could be simplified.

> src/hotspot/share/oops/method.cpp line 1304:
> 
>> 1302:     assert(blob->is_mh_intrinsic(), "must be MH intrinsic");
>> 1303:     MethodHandleIntrinsicBlob* mhi = blob->as_mh_intrinsic();
>> 1304:     return (mhi->method() == nullptr) || (mhi->method() == this);
> 
> The assert looks redundant, since the cast on the next line already checks it.
> 
> Also, can `mhi->method()` really be `nullptr` here?

No, it shouldn't be. Removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From duke at openjdk.java.net  Tue Jun  7 23:48:39 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 7 Jun 2022 23:48:39 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v2]
In-Reply-To: <1id0AtAL5Ux5ZhRL2HkgiOJ0amJycNFhUAnR9fsVbTA=.af3bca67-32e6-4e5f-b9ea-1a1825fec65d@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
 <1id0AtAL5Ux5ZhRL2HkgiOJ0amJycNFhUAnR9fsVbTA=.af3bca67-32e6-4e5f-b9ea-1a1825fec65d@github.com>
Message-ID: <ov193LAxjvho27ugl3KVtcer228mk7rbM5WaNFuYrwo=.578944cf-0c6e-4da0-9391-27de5ab8e881@github.com>

On Sat, 4 Jun 2022 01:11:10 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.cpp line 342:
>> 
>>> 340: MethodHandleIntrinsicBlob* MethodHandleIntrinsicBlob::create(const methodHandle& method,
>>> 341:   CodeBuffer *code_buffer) {
>>> 342:   code_buffer->finalize_oop_references(method);
>> 
>> Can you please explain why this is needed? (I'm a bit surprised since the constructor asserts that `total_oop_size` is 0)
>> 
>> Thanks.
>
> I don't think finalize_oop_references() makes sense except for nmethods.  If the MH intrinsic could contain contain oops, then GC would need to be able to find and relocate them.

It is not needed. Removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8760

From duke at openjdk.java.net  Tue Jun  7 23:49:09 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 7 Jun 2022 23:49:09 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v2]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>

> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
> 
> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
> 
> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
> 
> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
> 
> Thanks in advance,
> Cesar

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

  fix last minute typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9074/files
  - new: https://git.openjdk.java.net/jdk/pull/9074/files/7c739f77..13fe3060

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/9074

From kvn at openjdk.java.net  Tue Jun  7 23:52:20 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 7 Jun 2022 23:52:20 GMT
Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <qQGkuNKrCk7itjglx2xOgMZHgu_lKkSgA_UHqXwZHL4=.cb24b622-6781-4931-987f-73e070e6488e@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

Is this C1 only issue? The comment in RFE shows that C2 does not have duplicated stubs. It is not clear from RFE.
If it is only C1 then I am not sure how profitable it is because C1 code is replaced with C2 generated code eventually.

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From sviswanathan at openjdk.java.net  Wed Jun  8 01:06:40 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 8 Jun 2022 01:06:40 GMT
Subject: RFR: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake [v2]
In-Reply-To: <DPBOSeqsfvw9AmqO7if7Mv0IO7MvzdtdJcIWunSIz98=.ea6fb39e-688c-4a4b-9956-9d8a5e432177@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
 <54Cx68cjFE-RfvwVJB92DhENPyRIwzhi3jfyG5ZGPSg=.563519e8-7880-4754-933c-78d66affabef@github.com>
 <m5KYufVAix0o5JcQZYp0WBnSkREPeyUdnNvZIyo4swk=.54b1c15d-c175-4e1c-952d-d523b8794780@github.com>
 <2ZEEJJQuJDrG1UuL6IOMr5nvCm1DCs2PLPp4y0Dpqag=.0d3588d9-6f49-43c6-bfbf-62cdb239450f@github.com>
 <TLcNVdtBnsiVG-_VsEtAcJ6qnaRmruR7sxS8uUD3Rp8=.3685585e-6ea3-4441-bcae-f1a2bde27f31@github.com>
 <AxXOZ_pZNLVq8WBmdB2S7n47TxeY8azMZED1QDyTXHM=.59ab2a26-a692-4bfa-aa06-b043966f69a7@github.com>
 <DPBOSeqsfvw9AmqO7if7Mv0IO7MvzdtdJcIWunSIz98=.ea6fb39e-688c-4a4b-9956-9d8a5e432177@github.com>
Message-ID: <WFcAdcrDlnp5evvbADgZjmHKQChoXXHjkN_n4wxB8pU=.b1d807e3-2e40-406f-89b8-8e09a138001d@github.com>

On Tue, 7 Jun 2022 23:22:42 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> @vnkozlov @jatin-bhateja Your review comments are implemented. Please take a look.
>
> @sviswa7, please, file separate RFE for SPECjvm2008-SOR.small issue (different unrolling factor).
> 
> I got all performance data from our and yours data and I think these change are ready for integration. Thanks!

@vnkozlov Thanks a lot. I have filed the RFE: https://bugs.openjdk.org/browse/JDK-8287966.

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From sviswanathan at openjdk.java.net  Wed Jun  8 01:07:53 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 8 Jun 2022 01:07:53 GMT
Subject: Integrated: 8287697: Limit auto vectorization to 32-byte vector on
 Cascade Lake
In-Reply-To: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
References: <RDVZrWFCyckyB0ufIkMIBKwRvDD1SvntKMt95iE9-6A=.5c9f124e-9da9-4062-9158-bcabad0cb102@github.com>
Message-ID: <SR2IQxW9Mir1-H9f3l3CusWmz4mQ0aaG7BbFmxtlQj0=.6fd8e69c-088c-4258-8a94-a2e60ecc52f4@github.com>

On Wed, 25 May 2022 01:48:16 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> We observe ~20% regression in SPECjvm2008 mpegaudio sub benchmark on Cascade Lake with Default vs -XX:UseAVX=2.
> The performance of all the other non-startup sub benchmarks of SPECjvm2008 is within +/- 5%. 
> The performance regression is due to auto-vectorization of small loops. 
> We don?t have AVX3Threshold consideration in auto-vectorization. 
> The performance regression in mpegaudio can be recovered by limiting auto-vectorization to 32-byte vectors.
> 
> This PR limits auto-vectorization to 32-byte vectors by default on Cascade Lake. Users can override this by either setting -XX:UseAVX=3 or -XX:SuperWordMaxVectorSize=64 on JVM command line.
> 
> Please review.
> 
> Best Regard,
> Sandhya

This pull request has now been integrated.

Changeset: 45f1b72a
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45f1b72a6ee5b86923c3217f101a90851c30401f
Stats:     48 lines in 6 files changed: 42 ins; 0 del; 6 mod

8287697: Limit auto vectorization to 32-byte vector on Cascade Lake

Reviewed-by: kvn, jbhateja

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

PR: https://git.openjdk.java.net/jdk/pull/8877

From jiefu at openjdk.java.net  Wed Jun  8 05:17:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 8 Jun 2022 05:17:06 GMT
Subject: RFR: 8287980: Build is broken due to SuperWordMaxVectorSize when C2 is
 disabled after JDK-8287697
Message-ID: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>

Hi all,

Please review this trivial patch which fixes the build broken when C2 is disabled due to `SuperWordMaxVectorSize`.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8287980: Build is broken due to SuperWordMaxVectorSize when C2 is disabled after JDK-8287697

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

PR: https://git.openjdk.java.net/jdk/pull/9078

From kvn at openjdk.java.net  Wed Jun  8 06:56:22 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 06:56:22 GMT
Subject: RFR: 8287980: Build is broken due to SuperWordMaxVectorSize when
 C2 is disabled after JDK-8287697
In-Reply-To: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>
References: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>
Message-ID: <EJ0rB2Sl1rRKNGoQGl1Rq33coDP3qbHw74aOWKXhV9s=.b8eafa47-800e-4a8f-aa0f-00ab253a46ef@github.com>

On Wed, 8 Jun 2022 05:07:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial patch which fixes the build broken when C2 is disabled due to `SuperWordMaxVectorSize`.
> 
> Thanks.
> Best regards,
> Jie

Trivial.
Thank you for fixing.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9078

From jiefu at openjdk.java.net  Wed Jun  8 06:56:22 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 8 Jun 2022 06:56:22 GMT
Subject: RFR: 8287980: Build is broken due to SuperWordMaxVectorSize when
 C2 is disabled after JDK-8287697
In-Reply-To: <EJ0rB2Sl1rRKNGoQGl1Rq33coDP3qbHw74aOWKXhV9s=.b8eafa47-800e-4a8f-aa0f-00ab253a46ef@github.com>
References: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>
 <EJ0rB2Sl1rRKNGoQGl1Rq33coDP3qbHw74aOWKXhV9s=.b8eafa47-800e-4a8f-aa0f-00ab253a46ef@github.com>
Message-ID: <99PfuRulWpHnc3lHq49J13XpBQU9MtSLJrvQgxl_JXY=.d66caad6-a6fe-4eb0-897d-4c4008dadbcb@github.com>

On Wed, 8 Jun 2022 06:53:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Trivial. Thank you for fixing.

Thanks @vnkozlov for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/9078

From jiefu at openjdk.java.net  Wed Jun  8 07:01:14 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 8 Jun 2022 07:01:14 GMT
Subject: Integrated: 8287980: Build is broken due to SuperWordMaxVectorSize
 when C2 is disabled after JDK-8287697
In-Reply-To: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>
References: <BqY9eHOE1u1kuv2d97ZnjVmcrgYQ3DySU5vVw4VvnfI=.07e76851-9b33-48c0-8e84-f0dcea4a5ef7@github.com>
Message-ID: <pLjvVfbaZH0yqg3nu9WPLswpsaW0CfVspwxJ_JGmZZs=.7fba3036-cdba-4c2c-acfb-f4ead4a0d271@github.com>

On Wed, 8 Jun 2022 05:07:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial patch which fixes the build broken when C2 is disabled due to `SuperWordMaxVectorSize`.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 47d3c2a1
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47d3c2a175a839add63d5453910e109923c41161
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8287980: Build is broken due to SuperWordMaxVectorSize when C2 is disabled after JDK-8287697

Reviewed-by: kvn

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

PR: https://git.openjdk.java.net/jdk/pull/9078

From mbaesken at openjdk.java.net  Wed Jun  8 07:24:36 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Jun 2022 07:24:36 GMT
Subject: RFR: JDK-8287735: Provide separate event category for dll
 operations
In-Reply-To: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
References: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
Message-ID: <zAVtwP3nNmkjGmyVVpoagweJVM4U9aaDkVw4O7lfNZg=.792ffdf1-184e-47f9-87c1-ec1cf26e1df0@github.com>

On Tue, 7 Jun 2022 10:36:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have a number of event categories logged and displayed in the hs_err file like
> Classes unloaded (0 events)
> Classes redefined (0 events)
> Internal exceptions (0 events)
> VM Operations (0 events)
> but the dll operations (like dll_load) go into the generic "Events" category where they usually are shifted out pretty fast.
> Better provide a separate category DLL operations for them.
> Currently the dll_load is logged.  Later dll_unload might be added.

Hi Thomas and Coleen, thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/9058

From mbaesken at openjdk.java.net  Wed Jun  8 07:24:37 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 8 Jun 2022 07:24:37 GMT
Subject: Integrated: JDK-8287735: Provide separate event category for dll
 operations
In-Reply-To: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
References: <N8uRF4dYwUbKpztaffiCApNv6a7tjlj3wG2quASeP8s=.1c0415a2-8d3f-4d13-8588-ba15fa731bbc@github.com>
Message-ID: <F--NeW_hfbn24QTcsrg3oXhz2luKTfeDgJDlTCM2fUs=.ba9dccc3-22b7-4c6a-8a3c-5b9157ffa09a@github.com>

On Tue, 7 Jun 2022 10:36:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we have a number of event categories logged and displayed in the hs_err file like
> Classes unloaded (0 events)
> Classes redefined (0 events)
> Internal exceptions (0 events)
> VM Operations (0 events)
> but the dll operations (like dll_load) go into the generic "Events" category where they usually are shifted out pretty fast.
> Better provide a separate category DLL operations for them.
> Currently the dll_load is logged.  Later dll_unload might be added.

This pull request has now been integrated.

Changeset: 230726ea
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/230726ea58041506157646b6efad0b5c4a012559
Stats:     27 lines in 6 files changed: 16 ins; 0 del; 11 mod

8287735: Provide separate event category for dll operations

Reviewed-by: coleenp, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/9058

From dchuyko at openjdk.java.net  Wed Jun  8 09:36:42 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Wed, 8 Jun 2022 09:36:42 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v4]
In-Reply-To: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
Message-ID: <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

Dmitry Chuyko 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:

 - Removed unnecessary changes (forced UseLSE, blank lines)
 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
 - Revert "hardlse feature"
   
   This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
 - Merge branch 'openjdk:master' into JDK-8282322
 - hardlse feature

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8779/files
  - new: https://git.openjdk.java.net/jdk/pull/8779/files/f7c8378a..89aa16ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=02-03

  Stats: 96710 lines in 1412 files changed: 42891 ins; 45330 del; 8489 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779

PR: https://git.openjdk.java.net/jdk/pull/8779

From duke at openjdk.java.net  Wed Jun  8 09:39:23 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:39:23 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - remove comments
 - review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9068/files
  - new: https://git.openjdk.java.net/jdk/pull/9068/files/01c0a07c..b5627135

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9068&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9068&range=00-01

  Stats: 44 lines in 3 files changed: 32 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9068.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9068/head:pull/9068

PR: https://git.openjdk.java.net/jdk/pull/9068

From duke at openjdk.java.net  Wed Jun  8 09:39:23 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:39:23 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <atMhzgk19V6PQ5x0C8ALF0oJbrdFMj7OTQG9KMpQ1Mk=.a127e16d-dfcc-4222-8383-b9c22e26dead@github.com>
Message-ID: <L6oamAMB9cHdshHkUyEG3Bd7C62TTN1Ff8f7R3X6YSk=.e1c24d38-cac1-482b-9654-a9f69861ba46@github.com>

On Tue, 7 Jun 2022 17:41:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove comments
>>  - review comments
>
> src/hotspot/share/opto/subnode.hpp line 217:
> 
>> 215: //------------------------------CmpU3Node--------------------------------------
>> 216: // Compare 2 unsigned values, returning integer value (-1, 0 or 1).
>> 217: class CmpU3Node : public CmpUNode {
> 
> Place it after `CmpUNode` class.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/9068

From dchuyko at openjdk.java.net  Wed Jun  8 09:41:38 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Wed, 8 Jun 2022 09:41:38 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v3]
In-Reply-To: <o2_MxrhVy5YCxmEiiR4Gnxh6eHSwaKamfKda1VGIf34=.4f1040c3-ef0b-4847-89ac-3b63e63edd66@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <L1AQxM-yM7o66k6hUAFIt18OVUqF8_Ob63_WVW0hGZI=.a6aceaa5-5bcc-41e7-94d1-7856c7f99b2e@github.com>
 <o2_MxrhVy5YCxmEiiR4Gnxh6eHSwaKamfKda1VGIf34=.4f1040c3-ef0b-4847-89ac-3b63e63edd66@github.com>
Message-ID: <LiPu5aCQdPVakxtWI8ug229DAzO8mjk5NkJQZhB2f3k=.6304aa75-9a86-495d-9b5a-429dcfb6c187@github.com>

On Tue, 24 May 2022 06:54:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dmitry Chuyko 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 JDK-8282322
>>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>>  - Revert "hardlse feature"
>>    
>>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>>  - Merge branch 'openjdk:master' into JDK-8282322
>>  - hardlse feature
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 257:
> 
>> 255: // Forcibly enable runtime LSE support
>> 256:   FLAG_SET_DEFAULT(UseLSE, true);
>> 257: #else
> 
> I don't believe this block does anything useful, and it disables `-XX:-UseLSE` for testing.

Agree, I restored original detection code (it just does what we need on the right hardware).

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

PR: https://git.openjdk.java.net/jdk/pull/8779

From dchuyko at openjdk.java.net  Wed Jun  8 09:41:40 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Wed, 8 Jun 2022 09:41:40 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v2]
In-Reply-To: <o2_MxrhVy5YCxmEiiR4Gnxh6eHSwaKamfKda1VGIf34=.4f1040c3-ef0b-4847-89ac-3b63e63edd66@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <L1AQxM-yM7o66k6hUAFIt18OVUqF8_Ob63_WVW0hGZI=.a6aceaa5-5bcc-41e7-94d1-7856c7f99b2e@github.com>
 <o2_MxrhVy5YCxmEiiR4Gnxh6eHSwaKamfKda1VGIf34=.4f1040c3-ef0b-4847-89ac-3b63e63edd66@github.com>
Message-ID: <_i70e42J1C93w4kuAn-HmoC_cNGgLcQulOUWCetduqQ=.61797940-3706-4fbe-89b3-faebe0e0e147@github.com>

On Tue, 24 May 2022 06:55:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dmitry Chuyko has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>>  - Revert "hardlse feature"
>>    
>>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>
> src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 25:
> 
>> 23:         .globl aarch64_atomic_fetch_add_8_default_impl
>> 24:         .align 5
>> 25: aarch64_atomic_fetch_add_8_default_impl:
> 
> Don't delete this blank line.

Fine, excluded this part.

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

PR: https://git.openjdk.java.net/jdk/pull/8779

From duke at openjdk.java.net  Wed Jun  8 09:42:32 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 8 Jun 2022 09:42:32 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:

                                                    Before          After
    Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
    Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
    Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op

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

PR: https://git.openjdk.java.net/jdk/pull/9068

From bulasevich at openjdk.java.net  Wed Jun  8 10:36:34 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Wed, 8 Jun 2022 10:36:34 GMT
Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <fn_IUZU92NsxfwPWQE6aeZCl-jRwKMD1juWm46qvg2M=.a8de6678-506b-4ab4-96ef-88c103085080@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

src/hotspot/cpu/x86/x86_32.ad line 1816:

> 1814:                      rspec, RELOC_DISP32);
> 1815:       __ post_call_nop();
> 1816:       address mark = cbuf.insts_mark();

no need to init `address mark` here. 
`emit_to_interp_stub` can do it internally as it worked before

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From duke at openjdk.java.net  Wed Jun  8 11:57:17 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 8 Jun 2022 11:57:17 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v4]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <8vcHIm_BP_d1lTHFjoucth390fQ1nqL2Crsr2DXpkT0=.5a7090a8-4166-4c8b-903c-3f1c794efc67@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/0b83cb44..2bce45d0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Wed Jun  8 12:36:17 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 8 Jun 2022 12:36:17 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v5]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <Zf81iVwMrzmjCTUjTIZQY8VL-bOA6UhCVlI34dCqI5U=.6be3c2f2-7180-4f76-a39e-7ae9be23ec7b@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Extract UL printing to method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/2bce45d0..c269810c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=03-04

  Stats: 31 lines in 2 files changed: 19 ins; 9 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812

PR: https://git.openjdk.java.net/jdk/pull/8812

From rpressler at openjdk.java.net  Wed Jun  8 12:45:22 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Wed, 8 Jun 2022 12:45:22 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <0EUT0JCMFuP56MkUjJINqeRVf_EFxQNulXo0Y9xgtuQ=.779c231e-854a-4a16-8293-37778281de8b@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

I've read some about the ARM PAC feature, and it seems that pointers are signed after being combined with any arbitrary value stored in some register. The current implementation uses a frame pointer value in the fp register as the other register, which is not only problematic for virtual threads, but with some future planned repurposing of that register. Perhaps some other secret value, that is amenable to copying stacks, could be used to achieve the same effect (although not in JDK 19, obviously).

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From duke at openjdk.java.net  Wed Jun  8 12:57:56 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 8 Jun 2022 12:57:56 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v6]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <-sL23oWJQGg6b54V_s_MTxoJC-VpH4qERBKm8cuRssw=.8c2377a5-4de6-4ef9-8f09-ecee7a8c654d@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify code
 - Refactor using LogStream

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/c269810c..1eddf482

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=04-05

  Stats: 37 lines in 2 files changed: 17 ins; 9 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Wed Jun  8 12:59:55 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 8 Jun 2022 12:59:55 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v3]
In-Reply-To: <Gr8S9EhDipTwTnKZxzTSRCO19IHKK5g_SLOzg6rcqq0=.69ddd93b-e8d2-41f9-9e63-89174cb3a240@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <D8hHAAm3K-F_sZj-c3iyx7_QJChhusYp8-Bga9FWHXw=.a90a8172-bfd3-46a3-9ae2-baec40b0775b@github.com>
 <Gr8S9EhDipTwTnKZxzTSRCO19IHKK5g_SLOzg6rcqq0=.69ddd93b-e8d2-41f9-9e63-89174cb3a240@github.com>
Message-ID: <E8xM_HLho9GYcTKQzw_JxjBRIMZS5nSS_F1dAUB8SA0=.3ac2dfde-3119-4bc0-9660-03a1c2791c8a@github.com>

On Tue, 7 Jun 2022 18:45:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove superfluous if stmt
>
> src/hotspot/share/runtime/deoptimization.cpp line 1937:
> 
>> 1935:       char* name_sig = tm->name_and_sig_as_C_string();
>> 1936:       const char* reason_name = Deoptimization::trap_reason_name(reason);
>> 1937:       const char* reason_action = Deoptimization::trap_action_name(action);
> 
> What is the reason to specify `Deoptimization::` in these calls?

Thanks, removed :-).

> src/hotspot/share/runtime/deoptimization.cpp line 1941:
> 
>> 1939:       log_debug(deoptimization)("cid: %d osr: %s level: %d %s @ %d %s -> %s",
>> 1940:                                 nm->compile_id(),
>> 1941:                                 (nm->is_osr_method() ? "true" : "false"),
> 
> Since it is one-liner it should follow how we print for `-Xlog:jit+compilation=debug`: 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compileTask.cpp#L482
> 
> [0.142s][debug][jit,compilation]    6 %     4       Reproducer::run @ 8 (39 bytes)
> 
> Of cause we can use `osr` instead of `%` in output to be clear.
> 
> You can simplify `osr: %s` print by `%s` and `(nm->is_osr_method() ? "osr" : "   ")`
> You also need to print `osr_bci` - we can have separate compilations of the same method for different `bci`.
> Also print `p2i(fr.pc())` and relative PC which very useful:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1883

This is the current log line (w/o "osr"), it's become quite long.

`[12,240s][debug][deoptimization] cid=135  pc=0x00007fa4dcbef5d4 relative_pc=0x0000000000000154 level=4 java.util.concurrent.locks.ReentrantLock$Sync::tryRelease @ 26 unstable_if reinterpret`

I changed to `=` to make it consistent with the latter example you posted. `osr_bci` is added after the `trap_bci`. I also refactored logging into using `LogStream` in a separate method, but the common logging block is still inline.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From ngasson at openjdk.java.net  Wed Jun  8 13:07:24 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 8 Jun 2022 13:07:24 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <V7PZQLpC8UEaR1KrPtgRLRLQBIyBl7f-j8i-8zIsZKM=.be7b736c-29f0-48d6-a2ef-50a1ab15b56b@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

Yes the current implementation uses the frame pointer for signing/authentication so `-XX:UseBranchProtection=pac-ret` turns on `PreserveFramePointer`. 

For now I can make another patch that disables PAC-RET when `Arguments::enable_preview()` is true.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From bulasevich at openjdk.java.net  Wed Jun  8 13:30:26 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Wed, 8 Jun 2022 13:30:26 GMT
Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <t1Gigc1XLRETSXriG2Bw9-zZGbaJxxIj-Hda3sRBGf8=.60774236-39cc-4f39-b757-076d33af675b@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

Based on your numbers (bytes saved / number of methods) I believe we're saving 16 bytes per method. How much more is there? What can we do with stubs besides duplicated static stubs removal? Is it possible (theoretically) to move the stub out of the calling method to share it between methods?

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From duke at openjdk.java.net  Wed Jun  8 13:44:16 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 8 Jun 2022 13:44:16 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <qQGkuNKrCk7itjglx2xOgMZHgu_lKkSgA_UHqXwZHL4=.cb24b622-6781-4931-987f-73e070e6488e@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <qQGkuNKrCk7itjglx2xOgMZHgu_lKkSgA_UHqXwZHL4=.cb24b622-6781-4931-987f-73e070e6488e@github.com>
Message-ID: <QBIsvEazVLXqnMbimr3ZXR5P9uW2_K217azHYGRnPNs=.be52057a-8891-4267-a6df-b53a033c23e5@github.com>

On Tue, 7 Jun 2022 23:48:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Is this C1 only issue? The comment in RFE shows that C2 does not have duplicated stubs. It is not clear from RFE. If it is only C1 then I am not sure how profitable it is because C1 code is replaced with C2 generated code eventually.

Both C1 and C2 have the issue. The JBS issue has output from C1 and C2 showing the issue. I updated the issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From tschatzl at openjdk.java.net  Wed Jun  8 14:00:24 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Jun 2022 14:00:24 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
Message-ID: <mIss5IAjSNsNSlaY7loVJjHV2mg1VP1il9FZYbuLZxc=.166a1573-24f3-4aea-a4c2-05667b20c386@github.com>

On Wed, 1 Jun 2022 22:02:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8982

From duke at openjdk.java.net  Wed Jun  8 14:16:34 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 8 Jun 2022 14:16:34 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <t1Gigc1XLRETSXriG2Bw9-zZGbaJxxIj-Hda3sRBGf8=.60774236-39cc-4f39-b757-076d33af675b@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <t1Gigc1XLRETSXriG2Bw9-zZGbaJxxIj-Hda3sRBGf8=.60774236-39cc-4f39-b757-076d33af675b@github.com>
Message-ID: <B8WuOWl_39ppfyZuz8fAoCmlwSPvDzLFF1ikhF-N0S8=.fd498ddb-7854-4616-802c-a0675dbb031c@github.com>

On Wed, 8 Jun 2022 13:26:59 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Based on your numbers (bytes saved / number of methods) I believe we're saving 16 bytes per method.

How did you get 16? 
dotty arm64: $ 820544 / 4592 = 179 $

> How much more is there? What can we do with stubs besides duplicated static stubs removal?

For arm64 we have: moving a pointer to metadata to a register and moving the address of the interpreter to a register.

  0x0000ffff79bd2560: isb ; {static_stub}
  0x0000ffff79bd2564: mov x12, #0x388 // #904
                                                            ; {metadata({method} {0x0000ffff18400388} 'error' '(ILjava/lang/String;)V' in 'Test')}
  0x0000ffff79bd2568: movk x12, #0x1840, lsl #16
  0x0000ffff79bd256c: movk x12, #0xffff, lsl #32
  0x0000ffff79bd2570: mov x8, #0xe58c // #58764
  0x0000ffff79bd2574: movk x8, #0x793b, lsl #16
  0x0000ffff79bd2578: movk x8, #0xffff, lsl #32
  0x0000ffff79bd257c: br x8 

If we never patch the branch to the interpreter, we can optimize it at link time either to a direct branch or an adrp based far jump. I also created https://bugs.openjdk.org/browse/JDK-8286142 to reduce metadata mov instructions.

> Is it possible (theoretically) to move the stub out of the calling method to share it between methods?

It is possible but it complicates CodeCache maintenance. Stubs use a pointer to metadata. When a class and methods are unloaded, we will need to invalidate all corresponding stubs.

I can check with benchmarks how many stubs can shared among methods.

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From coleenp at openjdk.java.net  Wed Jun  8 14:49:42 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 8 Jun 2022 14:49:42 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
Message-ID: <q-gAqmSkqTKfRcALXudsGUn5uRdPeMAkhzgzpNtK4dw=.8a3efc3d-8a99-48f8-a278-07b40bfe8e36@github.com>

On Wed, 1 Jun 2022 22:02:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

Looks good! thank you for this change.

test/hotspot/gtest/unittest.hpp line 100:

> 98:     }                                                               \
> 99:     fprintf(stderr, "OKIDOKI");                                     \
> 100:     gtest_exit_from_child_vm(0);                                               \

Are the backslashes lined up here?  Can you line them up, if not?  Thanks for the comment why this function.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8982

From shade at openjdk.java.net  Wed Jun  8 15:28:57 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Jun 2022 15:28:57 GMT
Subject: RFR: 8288040: x86: Loom: Improve cont/monitor-count helper methods
Message-ID: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>

When doing x86_32 port, I realized that cont helper methods are sensitive to `rsp`, which makes the usual trick of using a scratch register for `thread` dangerous. We can just lift the entire thread-acquisition business into the methods themselves. Related to that, we can also do the same thing for monitor-count helper methods, thus fully isolating them from the caller code. It would be even better after [JDK-8286957](https://bugs.openjdk.org/browse/JDK-8286957).

This does the shared code change, so that x86_32 port can hopefully continue as late enhancement after RDP1.

Additional testing:
 - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
 - [x] Linux x86_32 fastdebug, `jdk_loom hotspot_loom`

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

Commit messages:
 - Revert unnecessary
 - Add a guard
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/9086/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9086&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288040
  Stats: 165 lines in 8 files changed: 86 ins; 44 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9086.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9086/head:pull/9086

PR: https://git.openjdk.java.net/jdk/pull/9086

From duke at openjdk.java.net  Wed Jun  8 16:24:44 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 8 Jun 2022 16:24:44 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <fn_IUZU92NsxfwPWQE6aeZCl-jRwKMD1juWm46qvg2M=.a8de6678-506b-4ab4-96ef-88c103085080@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <fn_IUZU92NsxfwPWQE6aeZCl-jRwKMD1juWm46qvg2M=.a8de6678-506b-4ab4-96ef-88c103085080@github.com>
Message-ID: <zW1ybuUXXxHOj3bVo6iUHxl1cCryCHoFDkrmfqoPJ6U=.94d3d5f7-57a8-41a0-973f-9da062d3aa20@github.com>

On Wed, 8 Jun 2022 10:32:34 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> ## Problem
>> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
>> 
>> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
>> 
>> Each Java call has:
>> - A relocation for a call site.
>> - A relocation for a stub to the interpreter.
>> - A stub to the interpreter.
>> - If far jumps are used (arm64 case):
>>   - A trampoline relocation.
>>   - A trampoline.
>> 
>> We cannot avoid creating relocations. They are needed to support patching call sites.
>> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
>> If we try to generate relocations as we go there will be a case which requires negative offsets:
>> 
>> reloc1  ---> 0x0: stub1
>> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
>> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
>> 
>> 
>> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
>> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
>> 
>> ## Solution
>> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
>> 
>> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
>> 
>> ## Results
>> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
>> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
>> - AArch64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      820544 |                       4592 |               18872 |
>> | dec-tree         |      405280 |                       2580 |               22335 |
>> | naive-bayes      |      392384 |                       2586 |               21184 |
>> | log-regression   |      362208 |                       2450 |               20325 |
>> | als              |      306048 |                       2226 |               18161 |
>> | finagle-chirper  |      262304 |                       2087 |               12675 |
>> | movie-lens       |      250112 |                       1937 |               13617 |
>> | gauss-mix        |      173792 |                       1262 |               10304 |
>> | finagle-http     |      164320 |                       1392 |               11269 |
>> | page-rank        |      155424 |                       1175 |               10330 |
>> | chi-square       |      140384 |                       1028 |                9480 |
>> | akka-uct         |      115136 |                        541 |                3941 |
>> | reactors         |       43264 |                        335 |                2503 |
>> | scala-stm-bench7 |       42656 |                        326 |                3310 |
>> | philosophers     |       36576 |                        256 |                2902 |
>> | scala-doku       |       35008 |                        231 |                2695 |
>> | rx-scrabble      |       32416 |                        273 |                2789 |
>> | future-genetic   |       29408 |                        260 |                2339 |
>> | scrabble         |       27968 |                        225 |                2477 |
>> | par-mnemonics    |       19584 |                        168 |                1689 |
>> | fj-kmeans        |       19296 |                        156 |                1647 |
>> | scala-kmeans     |       18080 |                        140 |                1629 |
>> | mnemonics        |       17408 |                        143 |                1512 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> - X86_64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      337065 |                       4403 |               19135 |
>> | dec-tree         |      183045 |                       2559 |               22071 |
>> | naive-bayes      |      176460 |                       2450 |               19782 |
>> | log-regression   |      162555 |                       2410 |               20648 |
>> | als              |      121275 |                       1980 |               17179 |
>> | movie-lens       |      111915 |                       1842 |               13020 |
>> | finagle-chirper  |      106350 |                       1947 |               12726 |
>> | gauss-mix        |       81975 |                       1251 |               10474 |
>> | finagle-http     |       80895 |                       1523 |               12294 |
>> | page-rank        |       68940 |                       1146 |               10124 |
>> | chi-square       |       62130 |                        974 |                9315 |
>> | akka-uct         |       50220 |                        555 |                4263 |
>> | reactors         |       23385 |                        371 |                2544 |
>> | philosophers     |       17625 |                        259 |                2865 |
>> | scala-stm-bench7 |       17235 |                        295 |                3230 |
>> | scala-doku       |       15600 |                        214 |                2698 |
>> | rx-scrabble      |       14190 |                        262 |                2770 |
>> | future-genetic   |       13155 |                        253 |                2318 |
>> | scrabble         |       12300 |                        217 |                2352 |
>> | fj-kmeans        |        8985 |                        157 |                1616 |
>> | par-mnemonics    |        8535 |                        155 |                1684 |
>> | scala-kmeans     |        8250 |                        138 |                1624 |
>> | mnemonics        |        7485 |                        134 |                1522 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> 
>> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
>> - `tier1`...`tier4`: Passed
>> - `hotspot/jtreg/compiler/sharedstubs`: Passed
>
> src/hotspot/cpu/x86/x86_32.ad line 1816:
> 
>> 1814:                      rspec, RELOC_DISP32);
>> 1815:       __ post_call_nop();
>> 1816:       address mark = cbuf.insts_mark();
> 
> no need to init `address mark` here. 
> `emit_to_interp_stub` can do it internally as it worked before

It is need for `mark_off`. I'll move it there.

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From duke at openjdk.java.net  Wed Jun  8 16:24:45 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 8 Jun 2022 16:24:45 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <zW1ybuUXXxHOj3bVo6iUHxl1cCryCHoFDkrmfqoPJ6U=.94d3d5f7-57a8-41a0-973f-9da062d3aa20@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <fn_IUZU92NsxfwPWQE6aeZCl-jRwKMD1juWm46qvg2M=.a8de6678-506b-4ab4-96ef-88c103085080@github.com>
 <zW1ybuUXXxHOj3bVo6iUHxl1cCryCHoFDkrmfqoPJ6U=.94d3d5f7-57a8-41a0-973f-9da062d3aa20@github.com>
Message-ID: <Xh9fYfWNQGANMy6N7fkub8tzmM1Dlcmh1xExLe9EeZw=.fa845ad4-0ef8-4e4b-8746-97f72f91af68@github.com>

On Wed, 8 Jun 2022 16:19:40 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/x86/x86_32.ad line 1816:
>> 
>>> 1814:                      rspec, RELOC_DISP32);
>>> 1815:       __ post_call_nop();
>>> 1816:       address mark = cbuf.insts_mark();
>> 
>> no need to init `address mark` here. 
>> `emit_to_interp_stub` can do it internally as it worked before
>
> It is need for `mark_off`. I'll move it there.

Or we can keep it and the code will be the same as in x86_64.ad.
What do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From kvn at openjdk.java.net  Wed Jun  8 17:45:58 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 17:45:58 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v6]
In-Reply-To: <-sL23oWJQGg6b54V_s_MTxoJC-VpH4qERBKm8cuRssw=.8c2377a5-4de6-4ef9-8f09-ecee7a8c654d@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <-sL23oWJQGg6b54V_s_MTxoJC-VpH4qERBKm8cuRssw=.8c2377a5-4de6-4ef9-8f09-ecee7a8c654d@github.com>
Message-ID: <MtYpoHixn6XH46Gne8T-KKyE__ZoIwE_hFDAuN_lxfQ=.cbf97003-eaa9-4bd0-a831-8d9149128a6a@github.com>

On Wed, 8 Jun 2022 12:57:56 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify code
>  - Refactor using LogStream

Few more comments.

src/hotspot/share/runtime/deoptimization.cpp line 1849:

> 1847:     ls.print("cid=%d %s pc=" INTPTR_FORMAT " relative_pc=" INTPTR_FORMAT " level=%d",
> 1848:              nm->compile_id(), (is_osr ? "%" : ""), pc, fr.pc() - nm->code_begin(),
> 1849:              nm->comp_level());

Please, print `pc` and `relative_pc` at the end of output.
I may be was not clear but do not use `%` for OSR marking. Please use your pattern to make it clear because you have other `bci`: `osr_bci=%d`

src/hotspot/share/runtime/deoptimization.cpp line 1852:

> 1850:     nm->method()->print_short_name(&ls);
> 1851:     ls.print(" @ ");
> 1852:     ls.print("%d ", trap_bci);

Instead of `@ %d` please use same pattern: `trap_bci=%d`.

src/hotspot/share/runtime/deoptimization.cpp line 1965:

> 1963:       Events::log_deopt_message(current, "Uncommon trap: reason=%s action=%s pc=" INTPTR_FORMAT " method=%s @ %d %s",
> 1964:                                 reason_name, reason_action, pc,
> 1965:                                 tm->name_and_sig_as_C_string(), trap_bci, nm->compiler_name());

I actually thought about putting all these logging (JFR, UL, Event) into separate method. But this looks fine as well - keep it.

src/hotspot/share/runtime/deoptimization.hpp line 172:

> 170: 
> 171:     // Does the actual work for deoptimizing a single frame
> 172:     static void deoptimize_single_frame(JavaThread* thread, frame fr, DeoptReason reason);

Please, keep original indent for this lines to match other line around. Actually `private:` has wrong additional space.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Wed Jun  8 17:46:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:46:33 GMT
Subject: RFR: 8285149: Using HashMap.newHashMap to replace new HashMap(int)
 [v4]
In-Reply-To: <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
 <zFlFjdt_WK9VyWsAxqnfhvu-MmJe1IKc7WtyBNkPE5A=.ec807db1-ad90-4e27-99d7-8a1ea145aa71@github.com>
 <S9LU83ceTWEKtLvzA4D63u3Qysv4rk6f83rZ7QvfR5E=.936ea9b1-c42b-47c7-8a98-4c8803c67fe8@github.com>
 <xW_IMRaU3A70QAxx5vnH990FVkxQnTq1EAf-F7rz3Nw=.17ca4b0e-ee2b-45bb-8cd1-c380bb6a0990@github.com>
 <4K3rhX2RGM_yaCKKJALcP7EplXS2pJXM8zYGNGEg-6Y=.c03f7730-b26a-459a-8d60-ea8ab9149603@github.com>
Message-ID: <I6KYBeCQX2UL3oyZRSoJS5kebHUgVdaeMie1rZaMmYo=.44589461-05c3-48f6-add0-9ef7fc6b7f69@github.com>

On Thu, 28 Apr 2022 16:33:48 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> I'm getting a bit tired of seeing these JDK wide changes with lots of files touched.
>> Delete all changes in desktop from this PR and re-submit them as a separate PR.
>> 
>> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and
>> run it on very old JDK versions to help track regressions.
>
> @prrace
> 
>> Delete all changes in desktop from this PR and re-submit them as a separate PR.
> 
> changes to java.desktop reverted.
> 
>> Also do not change J2DBench. We deliberately avoid using new API so that we can take it and run it on very old JDK versions to help track regressions.
> 
> For J2DBench, I don't see any changes that not complicated with older jdk version for now. please recheck. thanks.

> @XenoAmess This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

comment

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

PR: https://git.openjdk.java.net/jdk/pull/8301

From kvn at openjdk.java.net  Wed Jun  8 17:55:25 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 17:55:25 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
Message-ID: <ZiP4IVUuN_mMZtnOBclKUg1A6FisHxqJxV8pz7ebPpw=.8e22e84e-bc45-434c-97ca-eb323740ca20@github.com>

On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove comments
>  - review comments

Good. I submitted testing.
You need second review.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9068

From shade at openjdk.java.net  Wed Jun  8 18:02:58 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Jun 2022 18:02:58 GMT
Subject: RFR: 8288048: Build failure with GCC 6 after JDK-8286562
Message-ID: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>

[JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.

Additional testing:
 - [x] Linux x86_64 `fastdebug` build with GCC 6
 - [x] Linux x86_64 `fastdebug` build with GCC 9

@YaSuenag, if you could test with GCC 12, that would be helpful.

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/9090

From kvn at openjdk.java.net  Wed Jun  8 18:06:32 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 18:06:32 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v2]
In-Reply-To: <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
 <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>
Message-ID: <hNKocjSz7sfrqqKyE4X5Kf4NKHSaPu5ZXk1AUrMzT60=.344e5ee2-9a2f-407f-9e2a-ed9b58c7bd4a@github.com>

On Tue, 7 Jun 2022 23:49:09 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

>> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
>> 
>> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
>> 
>> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
>> 
>> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
>> 
>> Thanks in advance,
>> Cesar
>
> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix last minute typo

Nice work. I think we can target this for JDK 20. Please, update it to latest JDK - there are conflicts.

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

PR: https://git.openjdk.java.net/jdk/pull/9074

From coleenp at openjdk.java.net  Wed Jun  8 18:06:41 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 8 Jun 2022 18:06:41 GMT
Subject: RFR: 8288040: x86: Loom: Improve cont/monitor-count helper methods
In-Reply-To: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
References: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
Message-ID: <WEBQwwEWMgbsmcBAb9Oo47moV-D8ptWvt1Nd87vdaV0=.6e2350e3-fc5b-4f3e-8ce5-5a3f915472c7@github.com>

On Wed, 8 Jun 2022 15:21:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When doing x86_32 port, I realized that cont helper methods are sensitive to `rsp`, which makes the usual trick of using a scratch register for `thread` dangerous. We can just lift the entire thread-acquisition business into the methods themselves. Related to that, we can also do the same thing for monitor-count helper methods, thus fully isolating them from the caller code. It would be even better after [JDK-8286957](https://bugs.openjdk.org/browse/JDK-8286957).
> 
> This does the shared code change, so that x86_32 port can hopefully continue as late enhancement after RDP1.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_32 fastdebug, `jdk_loom hotspot_loom`

This is a useful refactoring.  Looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9086

From shade at openjdk.java.net  Wed Jun  8 18:14:57 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Jun 2022 18:14:57 GMT
Subject: RFR: 8288051: Loom: Extend the compilation warning workaround in stack
 chunk copy
Message-ID: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>

Current builds fail on some newer GCCs and some arches. There is already a workaround in place in one copy method, we need the workaround in another one too. I took a brief look if we could dispense with this workaround altogether, but that does not seem to be straight-forward for JDK 19 timeframe.


* For target hotspot_variant-server_libjvm_objs_continuationFreezeThaw.o:
In file included from /home/buildbot/shipilev-jdk/src/hotspot/share/classfile/javaClasses.inline.hpp:36,
                 from /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:26:
In member function 'void stackChunkOopDesc::copy_from_stack_to_chunk(intptr_t*, intptr_t*, int)',
    inlined from 'void FreezeBase::copy_to_chunk(intptr_t*, intptr_t*, int)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:499:34,
    inlined from 'freeze_result FreezeBase::recurse_freeze_stub_frame(frame&, frame&)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:1168:16:

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

Commit messages:
 - Fix
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/9091

From rpressler at openjdk.java.net  Wed Jun  8 18:25:38 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Wed, 8 Jun 2022 18:25:38 GMT
Subject: RFR: 8288040: x86: Loom: Improve cont/monitor-count helper methods
In-Reply-To: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
References: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
Message-ID: <1lSNZf2kaZ5yKFAFPz00blEl0S_1kMEr4YIIjzj8egw=.1702904a-9728-405f-8d2b-ec5ae8671648@github.com>

On Wed, 8 Jun 2022 15:21:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When doing x86_32 port, I realized that cont helper methods are sensitive to `rsp`, which makes the usual trick of using a scratch register for `thread` dangerous. We can just lift the entire thread-acquisition business into the methods themselves. Related to that, we can also do the same thing for monitor-count helper methods, thus fully isolating them from the caller code. It would be even better after [JDK-8286957](https://bugs.openjdk.org/browse/JDK-8286957).
> 
> This does the shared code change, so that x86_32 port can hopefully continue as late enhancement after RDP1.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_32 fastdebug, `jdk_loom hotspot_loom`

Look good. Thank you!

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

Marked as reviewed by rpressler (Author).

PR: https://git.openjdk.java.net/jdk/pull/9086

From coleenp at openjdk.java.net  Wed Jun  8 18:31:34 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 8 Jun 2022 18:31:34 GMT
Subject: RFR: 8288051: Loom: Extend the compilation warning workaround in
 stack chunk copy
In-Reply-To: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
References: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
Message-ID: <Psjjn024oCwL-5Oi5MCNF-0vu-14Elo86WtNwWW73SM=.3c35efae-102b-495b-85e0-37d514c82936@github.com>

On Wed, 8 Jun 2022 18:05:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current builds fail on some newer GCCs and some arches. There is already a workaround in place in one copy method, we need the workaround in another one too. I took a brief look if we could dispense with this workaround altogether, but that does not seem to be straight-forward for JDK 19 timeframe.
> 
> 
> * For target hotspot_variant-server_libjvm_objs_continuationFreezeThaw.o:
> In file included from /home/buildbot/shipilev-jdk/src/hotspot/share/classfile/javaClasses.inline.hpp:36,
>                  from /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:26:
> In member function 'void stackChunkOopDesc::copy_from_stack_to_chunk(intptr_t*, intptr_t*, int)',
>     inlined from 'void FreezeBase::copy_to_chunk(intptr_t*, intptr_t*, int)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:499:34,
>     inlined from 'freeze_result FreezeBase::recurse_freeze_stub_frame(frame&, frame&)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:1168:16:

Looks good, and thank you for the comment.  This also appears trivial.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9091

From kbarrett at openjdk.java.net  Wed Jun  8 18:53:26 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Jun 2022 18:53:26 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <rI_Qg3ghV_H35e1yUHtzLjKUkkluWSVCpsIo_h2IcVs=.d35b7dda-8b43-462d-93fa-f302b9bbe26c@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
 <rI_Qg3ghV_H35e1yUHtzLjKUkkluWSVCpsIo_h2IcVs=.d35b7dda-8b43-462d-93fa-f302b9bbe26c@github.com>
Message-ID: <c1KgCbp6fvgajrOE5FXSbBVBMVuld3m0RJZT0-bOdNQ=.685e6b2a-d6b0-43dd-b80c-953ca8ef1d96@github.com>

On Thu, 2 Jun 2022 13:06:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this new mechanism for "poisoning" uses of certain functions,
>> along with marking specific uses as still being permitted.  One use for this
>> is to discourage use of external library functions for which HotSpot provides
>> extended versions or portability shims.  Another is to prevent uses of certain
>> functions considered "insecure", promoting alternatives or requiring strong
>> scrutiny.
>> 
>> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
>> implementations.  Comments in the code describe the details.  For some
>> compilers we didn't find any features that would permit such poisoning.  As a
>> result, only shared code has complete coverage.
>> 
>> For gcc and clang we use an attribute that warns about references to an
>> annotated function, and scoped suppression of that warning.  This
>> functionality is provided since gcc9 and clang14.  (I haven't tested with
>> clang; version 14 is more recent than I have access for.  But the docs
>> describe an explicit match to the gcc functionality.)
>> 
>> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
>> deprecation annotations and scoped suppression of the consequent warnings
>> seemed plausible, but ran into problems.  (See comments in code for details.)
>> But we provide scoped suppression of deprecation warnings anyway.  Many of the
>> functions we'd poison are already conditionally deprecated under the control
>> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
>> we've removed or annotated all calls associated with one of those macros we
>> can remove the macro from our builds, preventing new uses from creeping into
>> unshared code.
>> 
>> The aix-ppc port doesn't provide poisoning support.  The version of clang used
>> by xlclang is older than the warning attribute and suppression.
>> 
>> Along with the new mechanisms, a few functions are poisoned by this change.
>> More functions can be added as folks have time to address their uses.
>> 
>> The poisoning declarations are in globalDefinitions.hpp, since the signatures
>> may use types that have platform-specific definitions or locations that are
>> provided within that header.  That header is included (directly or indirectly)
>> nearly everywhere, so provides good coverage.
>> 
>> The rest of the changes are to address existing uses of the newly forbidden
>> functions, either using something else or annotating them as permitted uses.
>
> Hi Kim,
> This seems fine to me.
> Thanks.

Thanks for reviews @dholmes-ora , @tschatzl , and @coleenp .

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

PR: https://git.openjdk.java.net/jdk/pull/8982

From kbarrett at openjdk.java.net  Wed Jun  8 18:53:28 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Jun 2022 18:53:28 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <q-gAqmSkqTKfRcALXudsGUn5uRdPeMAkhzgzpNtK4dw=.8a3efc3d-8a99-48f8-a278-07b40bfe8e36@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
 <q-gAqmSkqTKfRcALXudsGUn5uRdPeMAkhzgzpNtK4dw=.8a3efc3d-8a99-48f8-a278-07b40bfe8e36@github.com>
Message-ID: <hzcfgR-Z7P-kQrL5ubaCVfBjycWFPqGcJNUSDmszEmo=.603c60c2-4240-4792-a1a3-6254536ac095@github.com>

On Wed, 8 Jun 2022 14:46:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this new mechanism for "poisoning" uses of certain functions,
>> along with marking specific uses as still being permitted.  One use for this
>> is to discourage use of external library functions for which HotSpot provides
>> extended versions or portability shims.  Another is to prevent uses of certain
>> functions considered "insecure", promoting alternatives or requiring strong
>> scrutiny.
>> 
>> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
>> implementations.  Comments in the code describe the details.  For some
>> compilers we didn't find any features that would permit such poisoning.  As a
>> result, only shared code has complete coverage.
>> 
>> For gcc and clang we use an attribute that warns about references to an
>> annotated function, and scoped suppression of that warning.  This
>> functionality is provided since gcc9 and clang14.  (I haven't tested with
>> clang; version 14 is more recent than I have access for.  But the docs
>> describe an explicit match to the gcc functionality.)
>> 
>> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
>> deprecation annotations and scoped suppression of the consequent warnings
>> seemed plausible, but ran into problems.  (See comments in code for details.)
>> But we provide scoped suppression of deprecation warnings anyway.  Many of the
>> functions we'd poison are already conditionally deprecated under the control
>> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
>> we've removed or annotated all calls associated with one of those macros we
>> can remove the macro from our builds, preventing new uses from creeping into
>> unshared code.
>> 
>> The aix-ppc port doesn't provide poisoning support.  The version of clang used
>> by xlclang is older than the warning attribute and suppression.
>> 
>> Along with the new mechanisms, a few functions are poisoned by this change.
>> More functions can be added as folks have time to address their uses.
>> 
>> The poisoning declarations are in globalDefinitions.hpp, since the signatures
>> may use types that have platform-specific definitions or locations that are
>> provided within that header.  That header is included (directly or indirectly)
>> nearly everywhere, so provides good coverage.
>> 
>> The rest of the changes are to address existing uses of the newly forbidden
>> functions, either using something else or annotating them as permitted uses.
>
> test/hotspot/gtest/unittest.hpp line 100:
> 
>> 98:     }                                                               \
>> 99:     fprintf(stderr, "OKIDOKI");                                     \
>> 100:     gtest_exit_from_child_vm(0);                                               \
> 
> Are the backslashes lined up here?  Can you line them up, if not?  Thanks for the comment why this function.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8982

From kbarrett at openjdk.java.net  Wed Jun  8 19:22:48 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Jun 2022 19:22:48 GMT
Subject: RFR: 8214976: Warn about uses of functions replaced for
 portability [v2]
In-Reply-To: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
Message-ID: <Lk7_GeKeKCgTI35Tj-P5VzulsUsE0oqvC4dxHWtgGc4=.9183fe2e-5c2e-4f8a-a0f8-e78eebfaef8b@github.com>

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

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

 - Merge branch 'master' into disallow-functions
 - fix alignment of macro continuations
 - forbid direct calls to ::exit and ::_exit
 - forbid some functions
 - define macros

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8982/files
  - new: https://git.openjdk.java.net/jdk/pull/8982/files/b9cd6f3f..616b201b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8982&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8982&range=00-01

  Stats: 62326 lines in 929 files changed: 35418 ins; 20042 del; 6866 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8982/head:pull/8982

PR: https://git.openjdk.java.net/jdk/pull/8982

From kbarrett at openjdk.java.net  Wed Jun  8 19:22:49 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Jun 2022 19:22:49 GMT
Subject: Integrated: 8214976: Warn about uses of functions replaced for
 portability
In-Reply-To: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
References: <goHzWeSWvCkKWwQEARMosh6YflQ5w9CfdtiF4L1xpUc=.42fe1e82-125a-48a1-91b9-d6958f119111@github.com>
Message-ID: <EREv20I8zUzbtkdjmj83slilfG-5OOPfsMMQAbHlC_M=.bc9f16a3-ed8c-4f5b-bb18-1a0b505ca0bf@github.com>

On Wed, 1 Jun 2022 22:02:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this new mechanism for "poisoning" uses of certain functions,
> along with marking specific uses as still being permitted.  One use for this
> is to discourage use of external library functions for which HotSpot provides
> extended versions or portability shims.  Another is to prevent uses of certain
> functions considered "insecure", promoting alternatives or requiring strong
> scrutiny.
> 
> The new mechanism is defined in compilerWarnings.hpp, with compiler-specific
> implementations.  Comments in the code describe the details.  For some
> compilers we didn't find any features that would permit such poisoning.  As a
> result, only shared code has complete coverage.
> 
> For gcc and clang we use an attribute that warns about references to an
> annotated function, and scoped suppression of that warning.  This
> functionality is provided since gcc9 and clang14.  (I haven't tested with
> clang; version 14 is more recent than I have access for.  But the docs
> describe an explicit match to the gcc functionality.)
> 
> For Visual Studio I was unable to find a workable poisoning mechanism.  Using
> deprecation annotations and scoped suppression of the consequent warnings
> seemed plausible, but ran into problems.  (See comments in code for details.)
> But we provide scoped suppression of deprecation warnings anyway.  Many of the
> functions we'd poison are already conditionally deprecated under the control
> of macros like _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.  Once
> we've removed or annotated all calls associated with one of those macros we
> can remove the macro from our builds, preventing new uses from creeping into
> unshared code.
> 
> The aix-ppc port doesn't provide poisoning support.  The version of clang used
> by xlclang is older than the warning attribute and suppression.
> 
> Along with the new mechanisms, a few functions are poisoned by this change.
> More functions can be added as folks have time to address their uses.
> 
> The poisoning declarations are in globalDefinitions.hpp, since the signatures
> may use types that have platform-specific definitions or locations that are
> provided within that header.  That header is included (directly or indirectly)
> nearly everywhere, so provides good coverage.
> 
> The rest of the changes are to address existing uses of the newly forbidden
> functions, either using something else or annotating them as permitted uses.

This pull request has now been integrated.

Changeset: 04f02ac6
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04f02ac6b2ce496b86642987bb7e25d21b52a5b6
Stats:     154 lines in 11 files changed: 127 ins; 1 del; 26 mod

8214976: Warn about uses of functions replaced for portability

Reviewed-by: dholmes, tschatzl, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/8982

From sspitsyn at openjdk.java.net  Wed Jun  8 20:20:42 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 8 Jun 2022 20:20:42 GMT
Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2
 crashed: missing ThreadsListHandle in calling context
In-Reply-To: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
References: <hqTOAq5p0Oq9R_lcE6dE1jJLQzQMdcpq09QaE3RSVJA=.dac97265-b5b9-4763-877b-4bf14b3ebede@github.com>
Message-ID: <9ciuu4-zXPrex0fy0XoTTWjqLN6Aimh_u8EUPPsh_9I=.3e7a4750-936b-4c53-a1b6-0843151a11b0@github.com>

On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> A part of this issue was contributed with the following changeset:
> 
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +0000
> 
>     8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes
>     Reviewed-by: coleenp, sspitsyn, dholmes, rehn
> 
> The following change in `src/hotspot/share/runtime/thread.cpp` added new assert:
> 
> bool JavaThread::java_suspend() {
> - ThreadsListHandle tlh;
> - if (!tlh.includes(this)) {
> - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this));
> - return false;
> - }
> + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true),
>  + "missing ThreadsListHandle in calling context.");
>   return this->handshake_state()->suspend();
> }
> 
> This new assert misses a check for target thread as being current `JavaThread`.
> 
> Also, the JVMTI SuspendThread is protected with TLH:
> 
> JvmtiEnv::SuspendThread(jthread thread) {
>   JavaThread* current = JavaThread::current();
>   ThreadsListHandle tlh(current);              <= TLS defined here!!!
> 
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true); 
> 
> 
> However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH.
> The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below:
> 
> 
> @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) {
>  jvmtiError
>  JvmtiEnv::SuspendThread(jthread thread) {
>    JavaThread* current = JavaThread::current();
> -  ThreadsListHandle tlh(current);
> 
>    jvmtiError err;
>    JavaThread* java_thread = NULL;
>    oop thread_oop = NULL;
>    {
>      JvmtiVTMSTransitionDisabler disabler(true);
> +    ThreadsListHandle tlh(current);
> 
>      err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop);
>      if (err != JVMTI_ERROR_NONE) {
> 
> 
> 
> This problem exist in all JVMTI Suspend functions:
>  `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`.

Yes, I understand it. Thank you for clarification!

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

PR: https://git.openjdk.java.net/jdk/pull/8878

From dlong at openjdk.java.net  Wed Jun  8 20:23:37 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 8 Jun 2022 20:23:37 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <E8av2k6UmqWoP0hzF9U9A_3OrZ97KSLwrQZH2H9S0Pw=.8d649bfd-725c-4fb5-b44f-96ecd370fa3a@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

I don't see why we can't use the stack pointer instead of the frame pointer and get rid of the PreserveFramePointer requirement.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From rpressler at openjdk.java.net  Wed Jun  8 20:29:31 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Wed, 8 Jun 2022 20:29:31 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <E8av2k6UmqWoP0hzF9U9A_3OrZ97KSLwrQZH2H9S0Pw=.8d649bfd-725c-4fb5-b44f-96ecd370fa3a@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
 <E8av2k6UmqWoP0hzF9U9A_3OrZ97KSLwrQZH2H9S0Pw=.8d649bfd-725c-4fb5-b44f-96ecd370fa3a@github.com>
Message-ID: <RQGw-suhSDkXb2UxfvGYgMkqb5Zp3xvpoSGqQXnOs28=.ce31cd6e-6092-46b2-990f-8c1f2fde749e@github.com>

On Wed, 8 Jun 2022 20:19:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
>> 
>> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.
>
> I don't see why we can't use the stack pointer instead of the frame pointer and get rid of the PreserveFramePointer requirement.

@dean-long Which sp, though? The frame's ultimate sp? I I think interpreted frames don't know their sp when they're first constructed (and not sure about when they return). Or it could be the actual location of the return address, but I don't know what that means for the protection mechanism. On the other hand, the preserved fp is always the return address's location minus 1 anyway.

Either way, it's not the right value for Loom. We'll need to consider 1. how important is PAC for _Java_ frames, and 2. if it is important, what second value to use that is invariant under stack copying.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From dlong at openjdk.java.net  Wed Jun  8 22:43:31 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 8 Jun 2022 22:43:31 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <RQGw-suhSDkXb2UxfvGYgMkqb5Zp3xvpoSGqQXnOs28=.ce31cd6e-6092-46b2-990f-8c1f2fde749e@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
 <E8av2k6UmqWoP0hzF9U9A_3OrZ97KSLwrQZH2H9S0Pw=.8d649bfd-725c-4fb5-b44f-96ecd370fa3a@github.com>
 <RQGw-suhSDkXb2UxfvGYgMkqb5Zp3xvpoSGqQXnOs28=.ce31cd6e-6092-46b2-990f-8c1f2fde749e@github.com>
Message-ID: <InsHAYSKf5zvuF72SDuLk364Xsa9aeNvMMvBAwkie8c=.00849650-d637-4f9e-9fcf-f8d0abcb5431@github.com>

On Wed, 8 Jun 2022 20:26:26 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> I don't see why we can't use the stack pointer instead of the frame pointer and get rid of the PreserveFramePointer requirement.
>
> @dean-long Which sp, though? The frame's ultimate sp? I I think interpreted frames don't know their sp when they're first constructed (and not sure about when they return). Or it could be the actual location of the return address, but I don't know what that means for the protection mechanism. On the other hand, the preserved fp is always the return address's location minus 1 anyway.
> 
> Either way, it's not the right value for Loom. We'll need to consider 1. how important is PAC for _Java_ frames, and 2. if it is important, what second value to use that is invariant under stack copying.

@pron I don't think there is any reason why interpreted frames couldn't continue to use FP while compiled frames use SP.  It's not clear how useful PAC is for Java code at dynamic locations (how would the exploit find the ROP gadgets?).  I don't think there is a useful alternative to FP/SP that is invariant under stack copying.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From jiefu at openjdk.java.net  Wed Jun  8 23:43:18 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 8 Jun 2022 23:43:18 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
Message-ID: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>

Hi all,

Build failure was observed when build on a machine without clang.
Please review this trivial patch which fixes the build failure due to `__clang_major__` is not defined.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8288082: Build failure due to __clang_major__ is not defined after JDK-8214976

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From kvn at openjdk.java.net  Wed Jun  8 23:57:32 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 23:57:32 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v2]
In-Reply-To: <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <rgkmAsmrSupAPiEyO1O_NvPg8Ebaw9X-zGtrb5aql5I=.1cf7373d-f084-4ae1-936a-f6809933a455@github.com>
Message-ID: <ssBVpDU0sJdoTn-ZOEErALrTPwYaKYAO2bZRqgFQOpM=.cd7695b1-a59c-4a5a-83a8-5c34de37dc86@github.com>

On Wed, 8 Jun 2022 09:39:23 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove comments
>  - review comments

Tier1-4 testing passed - no new failures. I suggest to push it into JDK 20 after fork and after you get second review.

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

PR: https://git.openjdk.java.net/jdk/pull/9068

From dholmes at openjdk.java.net  Wed Jun  8 23:57:33 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Jun 2022 23:57:33 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
In-Reply-To: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
Message-ID: <Pa-3yiF2I0lIgdGWtQIRbOUKip0DiNQKmbItTD6dbYo=.07d1b228-d95b-4a4e-8cde-0a2b607541a7@github.com>

On Wed, 8 Jun 2022 23:36:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Build failure was observed when build on a machine without clang.
> Please review this trivial patch which fixes the build failure due to `__clang_major__` is not defined.
> 
> Thanks.
> Best regards,
> Jie

Thanks for the quick fix. I have no idea how this got passed our CI builds.

It is trivial so please push immediately.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9096

From jiefu at openjdk.java.net  Thu Jun  9 00:05:41 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 9 Jun 2022 00:05:41 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
In-Reply-To: <Pa-3yiF2I0lIgdGWtQIRbOUKip0DiNQKmbItTD6dbYo=.07d1b228-d95b-4a4e-8cde-0a2b607541a7@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
 <Pa-3yiF2I0lIgdGWtQIRbOUKip0DiNQKmbItTD6dbYo=.07d1b228-d95b-4a4e-8cde-0a2b607541a7@github.com>
Message-ID: <8qcwYDB9l81rDQf4ELrOTDvNbS6Bi3aiD3aXwNPxJ5U=.ac7de72b-9202-4a4d-800b-9f10bb90b5e0@github.com>

On Wed, 8 Jun 2022 23:54:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Thanks for the quick fix. I have no idea how this got passed our CI builds.
> 
> It is trivial so please push immediately.
> 
> Thanks.

Thanks @dholmes-ora for your review.

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From jiefu at openjdk.java.net  Thu Jun  9 00:05:42 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 9 Jun 2022 00:05:42 GMT
Subject: Integrated: 8288082: Build failure due to __clang_major__ is not
 defined after JDK-8214976
In-Reply-To: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
Message-ID: <9ClfVURh18m2TpsNfn0iU3ENL6grDVOypdFGPNl8gr4=.5547b21d-506f-4347-8d0e-96e8272d260c@github.com>

On Wed, 8 Jun 2022 23:36:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Build failure was observed when build on a machine without clang.
> Please review this trivial patch which fixes the build failure due to `__clang_major__` is not defined.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: a941bc2d
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a941bc2de674fdd77cdbbdf3641309fc39bfc0c4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288082: Build failure due to __clang_major__ is not defined after JDK-8214976

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From shade at openjdk.java.net  Thu Jun  9 05:52:26 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 05:52:26 GMT
Subject: RFR: 8288051: Loom: Extend the compilation warning workaround in
 stack chunk copy
In-Reply-To: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
References: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
Message-ID: <nLf65JFDv2HVKp8SkQR9r1TFXWYQlUFL4-nIDkYzSGA=.ff32e157-d2e5-45ea-85bf-188a7f4f7bcf@github.com>

On Wed, 8 Jun 2022 18:05:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current builds fail on some newer GCCs and some arches. There is already a workaround in place in one copy method, we need the workaround in another one too. I took a brief look if we could dispense with this workaround altogether, but that does not seem to be straight-forward for JDK 19 timeframe.
> 
> 
> * For target hotspot_variant-server_libjvm_objs_continuationFreezeThaw.o:
> In file included from /home/buildbot/shipilev-jdk/src/hotspot/share/classfile/javaClasses.inline.hpp:36,
>                  from /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:26:
> In member function 'void stackChunkOopDesc::copy_from_stack_to_chunk(intptr_t*, intptr_t*, int)',
>     inlined from 'void FreezeBase::copy_to_chunk(intptr_t*, intptr_t*, int)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:499:34,
>     inlined from 'freeze_result FreezeBase::recurse_freeze_stub_frame(frame&, frame&)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:1168:16:

Thank you for review!

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

PR: https://git.openjdk.java.net/jdk/pull/9091

From shade at openjdk.java.net  Thu Jun  9 05:52:26 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 05:52:26 GMT
Subject: Integrated: 8288051: Loom: Extend the compilation warning workaround
 in stack chunk copy
In-Reply-To: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
References: <HEVEyIpRCAGH3Wp8J5wBc32T1pA6hVhOYOIvr7t4BsQ=.d926c1fd-f2df-46e6-bdce-5a5ce786120f@github.com>
Message-ID: <S9LSmw_wNH35d8pZmJMhKhlZVZn_GqwGon7UIK64eLo=.fd38b1fc-072b-4718-beeb-5b79f6d9c325@github.com>

On Wed, 8 Jun 2022 18:05:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current builds fail on some newer GCCs and some arches. There is already a workaround in place in one copy method, we need the workaround in another one too. I took a brief look if we could dispense with this workaround altogether, but that does not seem to be straight-forward for JDK 19 timeframe.
> 
> 
> * For target hotspot_variant-server_libjvm_objs_continuationFreezeThaw.o:
> In file included from /home/buildbot/shipilev-jdk/src/hotspot/share/classfile/javaClasses.inline.hpp:36,
>                  from /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:26:
> In member function 'void stackChunkOopDesc::copy_from_stack_to_chunk(intptr_t*, intptr_t*, int)',
>     inlined from 'void FreezeBase::copy_to_chunk(intptr_t*, intptr_t*, int)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:499:34,
>     inlined from 'freeze_result FreezeBase::recurse_freeze_stub_frame(frame&, frame&)' at /home/buildbot/shipilev-jdk/src/hotspot/share/runtime/continuationFreezeThaw.cpp:1168:16:

This pull request has now been integrated.

Changeset: 7e1cce8c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e1cce8cb508a8af770443360721fbb3d3b40237
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8288051: Loom: Extend the compilation warning workaround in stack chunk copy

Reviewed-by: coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/9091

From kbarrett at openjdk.java.net  Thu Jun  9 06:33:25 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 9 Jun 2022 06:33:25 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
In-Reply-To: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
Message-ID: <nHMrTbHRE6GixvnTN9MUH1txkKe7GpULjimZN3zGYdI=.799c5711-ca22-41ad-a846-b2db6e6e4d1b@github.com>

On Wed, 8 Jun 2022 23:36:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Build failure was observed when build on a machine without clang.
> Please review this trivial patch which fixes the build failure due to `__clang_major__` is not defined.
> 
> Thanks.
> Best regards,
> Jie

Sorry about this.  I didn't realize we were building with `Wundef`.  I didn't have any failures in my testing because I was using gcc9+, so the offending expression doesn't get processed.  I think this only fails with gcc versions before 9.

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From jiefu at openjdk.java.net  Thu Jun  9 06:45:35 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 9 Jun 2022 06:45:35 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
In-Reply-To: <nHMrTbHRE6GixvnTN9MUH1txkKe7GpULjimZN3zGYdI=.799c5711-ca22-41ad-a846-b2db6e6e4d1b@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
 <nHMrTbHRE6GixvnTN9MUH1txkKe7GpULjimZN3zGYdI=.799c5711-ca22-41ad-a846-b2db6e6e4d1b@github.com>
Message-ID: <74RATbkjx2SxDRvQEb3NsliiMGZVaeL1xT0-wpwNVYA=.a4f2cf51-f9b5-447f-9b8a-0cfb2ae0feaf@github.com>

On Thu, 9 Jun 2022 06:30:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I think this only fails with gcc versions before 9.

Seems right.
The build failure was first observed with gcc8.

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From kbarrett at openjdk.java.net  Thu Jun  9 07:26:32 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 9 Jun 2022 07:26:32 GMT
Subject: RFR: 8288048: Build failure with GCC 6 after JDK-8286562
In-Reply-To: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
References: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
Message-ID: <VHKwhlr8Fp4iNwsRZuADIwjMBhHOH6S46wq1a0r_UrY=.0b2c0af8-bdbc-40ff-a620-26830cf9a84d@github.com>

On Wed, 8 Jun 2022 17:52:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug` build with GCC 6
>  - [x] Linux x86_64 `fastdebug` build with GCC 9
> 
> @YaSuenag, if you could test with GCC 12, that would be helpful.

So the `GCC diagnostic ignored` pragma doesn't ignore unknown warning options
the way `-Wno-xxx` is ignored for unknown `xxx` (unless there are other
warnings as well)? That's unfortunate, and kind of seems like a gcc bug. I
don't think there's an issue with it suppressing warnings for mistyped
options, since such a typo would lead to the warning one wants to suppress not
being suppressed, exposing the typo.  (Even if this were reported and such a
change were made, it wouldn't help with such an old compiler.)

The reason for using a specifically GCC disable there is because it's a
specifically GCC issue in this one place. Having to define a new macro for all
platforms for such a case seemed unwarranted. But the non-ignoring behavior
perhaps changes the calculation.

An alternative would be to disable `-Wunknown-pragmas` at the use-site, with a
comment about `-Wstringop-overflow` only being available since gcc7.

Another possibility would be to add `-Wunknown-pragmas` to the
PRAGMA_DISABLE_GCC_WARNING macro. (I think that's okay for the same reason I
think it would have been okay for gcc to ignore it in the first place.) But
maybe that's further than you want to (or should) go for the immediate issue,
and should instead be considered for a new RFE.

(And someday there should be a discussion about retiring support for older and
out of support versions of gcc.)

I *think* I have a mild preference for disabling `-Wunknown-pragmas` at the
use-site; uglifying the sole use-site to cope with a very specific issue at
that point seems maybe a little better than globally adding a new warning
ignorer (which may encourage future use rather than properly analyzing the
warnings; recall that most of the original warnings for this were addressed by
changing possibly questionable code).

But I won't insist on that approach, and am willing to accept this proposed
change as-is instead, hence marking it approved even though it's not my first
choice.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9090

From jiefu at openjdk.java.net  Thu Jun  9 07:38:32 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 9 Jun 2022 07:38:32 GMT
Subject: RFR: 8288082: Build failure due to __clang_major__ is not defined
 after JDK-8214976
In-Reply-To: <nHMrTbHRE6GixvnTN9MUH1txkKe7GpULjimZN3zGYdI=.799c5711-ca22-41ad-a846-b2db6e6e4d1b@github.com>
References: <Z5mKuo8O9drk1-JIicCM2It5IdHUrP-aVFjUSsVVGrU=.e4892ae0-51d6-4ba4-8084-7c9a11d7d191@github.com>
 <nHMrTbHRE6GixvnTN9MUH1txkKe7GpULjimZN3zGYdI=.799c5711-ca22-41ad-a846-b2db6e6e4d1b@github.com>
Message-ID: <Dt0--s7Y4QgGvWrgOlHaPUtRUGVOYKkXpvO-FxqxrsM=.1e13c481-6f1c-4277-946f-2e519509dcc8@github.com>

On Thu, 9 Jun 2022 06:30:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Sorry about this. I didn't realize we were building with `Wundef`. I didn't have any failures in my testing because I was using gcc9+, so the offending expression doesn't get processed. I think this only fails with gcc versions before 9.

I tested with gcc9 on Ubuntu 20.04.
Unfortunately, it fails to build.

ERROR: Build failed for target 'run-test' in configuration 'linux-x86_64-server-release' (exit code 2) 
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_os_posix.o:
In file included from /home/jdk/src/hotspot/share/utilities/compilerWarnings.hpp:32,
                 from /home/jdk/src/hotspot/share/utilities/globalDefinitions.hpp:28,
                 from /home/jdk/src/hotspot/share/memory/allocation.hpp:29,
                 from /home/jdk/src/hotspot/share/memory/arena.hpp:28,
                 from /home/jdk/src/hotspot/share/runtime/handles.hpp:28,
                 from /home/jdk/src/hotspot/share/classfile/classLoader.hpp:29,
                 from /home/jdk/src/hotspot/os/posix/os_posix.cpp:28:

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

PR: https://git.openjdk.java.net/jdk/pull/9096

From shade at openjdk.java.net  Thu Jun  9 07:39:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 07:39:32 GMT
Subject: RFR: 8288048: Build failure with GCC 6 after JDK-8286562
In-Reply-To: <VHKwhlr8Fp4iNwsRZuADIwjMBhHOH6S46wq1a0r_UrY=.0b2c0af8-bdbc-40ff-a620-26830cf9a84d@github.com>
References: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
 <VHKwhlr8Fp4iNwsRZuADIwjMBhHOH6S46wq1a0r_UrY=.0b2c0af8-bdbc-40ff-a620-26830cf9a84d@github.com>
Message-ID: <uuio2Fourzwvid8wLS8lg7q1pAXKw5urrYmX-D69R7U=.14b5d4c5-0b41-4ffd-a58c-70c4200735b5@github.com>

On Thu, 9 Jun 2022 07:22:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Another possibility would be to add `-Wunknown-pragmas` to the PRAGMA_DISABLE_GCC_WARNING macro. (I think that's okay for the same reason I think it would have been okay for gcc to ignore it in the first place.) 

Filed:
 https://bugs.openjdk.org/browse/JDK-8288093

> But I won't insist on that approach, and am willing to accept this proposed change as-is instead, hence marking it approved even though it's not my first choice.

Thank you. Would you consider this fix trivial? I'd like to get it before fork for RDP1. Otherwise I would need to push it to JDK 19 rampdown tree anyway.

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

PR: https://git.openjdk.java.net/jdk/pull/9090

From ngasson at openjdk.java.net  Thu Jun  9 08:13:43 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 08:13:43 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v4]
In-Reply-To: <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
Message-ID: <DvXgBVbJ2UbW-Xzc_QNf7nyLL_bXcYcbUR4R9cMAgXo=.0d7b672b-4d1e-4a0c-9cff-5807403a019b@github.com>

On Wed, 8 Jun 2022 09:36:42 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
>> 
>> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
>> 
>> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
>> 
>> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
>> 
>> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
>> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
>> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
>> 
>> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.
>
> Dmitry Chuyko 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:
> 
>  - Removed unnecessary changes (forced UseLSE, blank lines)
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>  - Revert "hardlse feature"
>    
>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - hardlse feature

Looks OK to me.

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

Marked as reviewed by ngasson (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8779

From shade at openjdk.java.net  Thu Jun  9 08:16:35 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 08:16:35 GMT
Subject: RFR: 8288040: x86: Loom: Improve cont/monitor-count helper methods
In-Reply-To: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
References: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
Message-ID: <5S6Do0EHtWYs5ccT_VcNWJRJAC9B6RKgxUsAvI11gCk=.8e4faad3-bd4b-435a-b30a-b664266fe0bd@github.com>

On Wed, 8 Jun 2022 15:21:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When doing x86_32 port, I realized that cont helper methods are sensitive to `rsp`, which makes the usual trick of using a scratch register for `thread` dangerous. We can just lift the entire thread-acquisition business into the methods themselves. Related to that, we can also do the same thing for monitor-count helper methods, thus fully isolating them from the caller code. It would be even better after [JDK-8286957](https://bugs.openjdk.org/browse/JDK-8286957).
> 
> This does the shared code change, so that x86_32 port can hopefully continue as late enhancement after RDP1.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_32 fastdebug, `jdk_loom hotspot_loom`

Thanks for reviews! I'll integrate to fit JDK 19 rampdown date today.

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

PR: https://git.openjdk.java.net/jdk/pull/9086

From bulasevich at openjdk.java.net  Thu Jun  9 08:20:27 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 08:20:27 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <Xh9fYfWNQGANMy6N7fkub8tzmM1Dlcmh1xExLe9EeZw=.fa845ad4-0ef8-4e4b-8746-97f72f91af68@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <fn_IUZU92NsxfwPWQE6aeZCl-jRwKMD1juWm46qvg2M=.a8de6678-506b-4ab4-96ef-88c103085080@github.com>
 <zW1ybuUXXxHOj3bVo6iUHxl1cCryCHoFDkrmfqoPJ6U=.94d3d5f7-57a8-41a0-973f-9da062d3aa20@github.com>
 <Xh9fYfWNQGANMy6N7fkub8tzmM1Dlcmh1xExLe9EeZw=.fa845ad4-0ef8-4e4b-8746-97f72f91af68@github.com>
Message-ID: <j9byyKmflok92f-PqqRpHtBicapnratlZX5L2cq4n4g=.d838f9d8-44f7-49ae-b57c-7413c10dab32@github.com>

On Wed, 8 Jun 2022 16:22:07 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> It is need for `mark_off`. I'll move it there.
>
> Or we can keep it and the code will be the same as in x86_64.ad.
> What do you think?

agree

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

PR: https://git.openjdk.java.net/jdk/pull/8816

From shade at openjdk.java.net  Thu Jun  9 08:20:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 08:20:36 GMT
Subject: Integrated: 8288040: x86: Loom: Improve cont/monitor-count helper
 methods
In-Reply-To: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
References: <isr8lYxyyQx_-us4u_b4bvMqovB9ReQuwx7H_6sHqYM=.d91d92f5-f6b3-472c-a6dc-389ccda72041@github.com>
Message-ID: <YXtnZ6cdGe7pN_kYMEx41jE1n-eI1Wm4Tw9WMK79Ldc=.2f40b360-5c04-4fa1-8a69-b72ea7218c76@github.com>

On Wed, 8 Jun 2022 15:21:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When doing x86_32 port, I realized that cont helper methods are sensitive to `rsp`, which makes the usual trick of using a scratch register for `thread` dangerous. We can just lift the entire thread-acquisition business into the methods themselves. Related to that, we can also do the same thing for monitor-count helper methods, thus fully isolating them from the caller code. It would be even better after [JDK-8286957](https://bugs.openjdk.org/browse/JDK-8286957).
> 
> This does the shared code change, so that x86_32 port can hopefully continue as late enhancement after RDP1.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_32 fastdebug, `jdk_loom hotspot_loom`

This pull request has now been integrated.

Changeset: e5b56baf
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e5b56bafa9ed68dec82adebc3eb298b70df7faeb
Stats:     165 lines in 8 files changed: 86 ins; 44 del; 35 mod

8288040: x86: Loom: Improve cont/monitor-count helper methods

Reviewed-by: coleenp, rpressler

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

PR: https://git.openjdk.java.net/jdk/pull/9086

From ngasson at openjdk.java.net  Thu Jun  9 08:31:32 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 08:31:32 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <V7PZQLpC8UEaR1KrPtgRLRLQBIyBl7f-j8i-8zIsZKM=.be7b736c-29f0-48d6-a2ef-50a1ab15b56b@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
 <V7PZQLpC8UEaR1KrPtgRLRLQBIyBl7f-j8i-8zIsZKM=.be7b736c-29f0-48d6-a2ef-50a1ab15b56b@github.com>
Message-ID: <nRRSkqIm_I8mTav_1NZs-X7LarWzNczaWiS6iDH_5Gk=.620eb979-8e6e-4338-819e-c3e7f14fc27d@github.com>

On Wed, 8 Jun 2022 13:04:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> 
> For now I can make another patch that disables PAC-RET when `Arguments::enable_preview()` is true.

See #9102

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From ngasson at openjdk.java.net  Thu Jun  9 08:36:04 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 08:36:04 GMT
Subject: RFR: 8288023: AArch64: disable PAC-RET when preview is enabled
Message-ID: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>

PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally
`-XX:UseBranchProtection=pac-ret` enables `PreserveFramePointer` which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark).  So for now just disable PAC when `--enable-preview` was also passed.

See some earlier discussion here: #9067

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

Commit messages:
 - 8288023: AArch64: disable PAC-RET when preview is enabled

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

PR: https://git.openjdk.java.net/jdk/pull/9102

From maxim.kartashev at jetbrains.com  Thu Jun  9 08:39:10 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Thu, 9 Jun 2022 11:39:10 +0300
Subject: Why no hs_err on SIGABRT?
Message-ID: <CAG0Tb0hZ2HiL07K29P3_7CKGc9sfA2h3=bb_E9dwzja=QWq9VA@mail.gmail.com>

The very useful hs_err file gets generated in many abnormal situations, but
program termination by abort() (which generates SIGABRT) isn't one of them.
I was wondering if this is deliberate and, if so, why?

The use case I have in mind is the utilization of the built-in GNU libc
heap checks. If, for example, there's a double-free, a chance exists for
those checks to fire and terminate the program with abort(). In absence of
core dump, hs_err would provide at least some guidance as to the location
of the problematic code and, unlike the core file, it will have the java
stack readily available. It is also quite common for the developers to
receive hs_err files, but not core files, which are a lot larger, may have
sensitive information in them, and are often not generated by default.

From aph at openjdk.java.net  Thu Jun  9 08:59:39 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 9 Jun 2022 08:59:39 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v4]
In-Reply-To: <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
Message-ID: <1b4wdroArKPV_H9rNh7xSScwl1_mYObW8ab4dk5UXjI=.cd449315-f98e-4525-bebe-6755f392bab6@github.com>

On Wed, 8 Jun 2022 09:36:42 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
>> 
>> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
>> 
>> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
>> 
>> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
>> 
>> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
>> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
>> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
>> 
>> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.
>
> Dmitry Chuyko 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:
> 
>  - Removed unnecessary changes (forced UseLSE, blank lines)
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>  - Revert "hardlse feature"
>    
>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - hardlse feature

src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 266:

> 264: aarch64_atomic_cmpxchg_4_relaxed_default_impl:
> 265: #ifdef __ARM_FEATURE_ATOMICS
> 266:         prfm    pstl1strm, [x0]

This still looks wrong. You do want PRFM before LDXR, surely. Not before CAS.

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

PR: https://git.openjdk.java.net/jdk/pull/8779

From bulasevich at openjdk.java.net  Thu Jun  9 09:24:20 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 09:24:20 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v2]
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <1e9QiLAFJUcvVzdleg9aeWTb4V7_SjL3NaGeQqiAJaw=.bc3a136d-3570-4eac-9b9c-c93cc4b71f62@github.com>

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

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

  cleanup and comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8453/files
  - new: https://git.openjdk.java.net/jdk/pull/8453/files/7799fea3..43a69437

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=00-01

  Stats: 13 lines in 5 files changed: 8 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8453.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8453/head:pull/8453

PR: https://git.openjdk.java.net/jdk/pull/8453

From rpressler at openjdk.java.net  Thu Jun  9 09:31:32 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Thu, 9 Jun 2022 09:31:32 GMT
Subject: RFR: 8288023: AArch64: disable PAC-RET when preview is enabled
In-Reply-To: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
References: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
Message-ID: <ORdmQC_cv4Zg46vNuaPyD5zWE9C2CjtqWE9AUgnvbdU=.5c5d99a9-3b92-402e-8ea8-e36b054c269a@github.com>

On Thu, 9 Jun 2022 08:26:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally
> `-XX:UseBranchProtection=pac-ret` enables `PreserveFramePointer` which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark).  So for now just disable PAC when `--enable-preview` was also passed.
> 
> See some earlier discussion here: #9067

Looks good. Thank you!

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

Marked as reviewed by rpressler (Author).

PR: https://git.openjdk.java.net/jdk/pull/9102

From adinn at openjdk.java.net  Thu Jun  9 09:35:46 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 9 Jun 2022 09:35:46 GMT
Subject: RFR: 8288023: AArch64: disable PAC-RET when preview is enabled
In-Reply-To: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
References: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
Message-ID: <SOzDYSk2rx81o29x8v09QZ0GZw_Vp5qdgAYRYqMZYfs=.f7fd8d1e-7ed6-4658-be20-290d03b5c55f@github.com>

On Thu, 9 Jun 2022 08:26:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally
> `-XX:UseBranchProtection=pac-ret` enables `PreserveFramePointer` which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark).  So for now just disable PAC when `--enable-preview` was also passed.
> 
> See some earlier discussion here: #9067

Looks good.

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

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9102

From rpressler at openjdk.java.net  Thu Jun  9 09:45:32 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Thu, 9 Jun 2022 09:45:32 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <InsHAYSKf5zvuF72SDuLk364Xsa9aeNvMMvBAwkie8c=.00849650-d637-4f9e-9fcf-f8d0abcb5431@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
 <E8av2k6UmqWoP0hzF9U9A_3OrZ97KSLwrQZH2H9S0Pw=.8d649bfd-725c-4fb5-b44f-96ecd370fa3a@github.com>
 <RQGw-suhSDkXb2UxfvGYgMkqb5Zp3xvpoSGqQXnOs28=.ce31cd6e-6092-46b2-990f-8c1f2fde749e@github.com>
 <InsHAYSKf5zvuF72SDuLk364Xsa9aeNvMMvBAwkie8c=.00849650-d637-4f9e-9fcf-f8d0abcb5431@github.com>
Message-ID: <h5vGL2vGc_4QtSst-Kv2VH_zmACtiPVUhbSsAlXt8wo=.d062edfd-a6f6-47e8-a9ab-25049e8df40e@github.com>

On Wed, 8 Jun 2022 22:40:02 GMT, Dean Long <dlong at openjdk.org> wrote:

>> @dean-long Which sp, though? The frame's ultimate sp? I I think interpreted frames don't know their sp when they're first constructed (and not sure about when they return). Or it could be the actual location of the return address, but I don't know what that means for the protection mechanism. On the other hand, the preserved fp is always the return address's location minus 1 anyway.
>> 
>> Either way, it's not the right value for Loom. We'll need to consider 1. how important is PAC for _Java_ frames, and 2. if it is important, what second value to use that is invariant under stack copying.
>
> @pron I don't think there is any reason why interpreted frames couldn't continue to use FP while compiled frames use SP.  It's not clear how useful PAC is for Java code at dynamic locations (how would the exploit find the ROP gadgets?).  I don't think there is a useful alternative to FP/SP that is invariant under stack copying.

@dean-long Thing is, I don't know the requirement on the second value. [This](https://developer.arm.com/documentation/102433/0100/Return-oriented-programming) suggests that even a constant value of zero can be used, and perhaps we could do better (?) by using some thread/continuation id, assuming this is useful at all for Java frames. In particular, if the attacker knows the location of the return address, then they also know the value of (a preserved) fp. Perhaps @nick-arm can enlighten us.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From rpressler at openjdk.java.net  Thu Jun  9 09:52:33 2022
From: rpressler at openjdk.java.net (Ron Pressler)
Date: Thu, 9 Jun 2022 09:52:33 GMT
Subject: RFR: 8288023: AArch64: disable PAC-RET when preview is enabled
In-Reply-To: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
References: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
Message-ID: <Tg272yZbqb3jr9ybXvwJ6_gz8v8akPOBAcp4DqhmAV8=.0612d782-fe64-4e78-8a13-fcd017d81b55@github.com>

On Thu, 9 Jun 2022 08:26:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally
> `-XX:UseBranchProtection=pac-ret` enables `PreserveFramePointer` which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark).  So for now just disable PAC when `--enable-preview` was also passed.
> 
> See some earlier discussion here: #9067

@nick-arm If you integrate over the next couple of hours this will make it in before the 19 fork.

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

PR: https://git.openjdk.java.net/jdk/pull/9102

From ngasson at openjdk.java.net  Thu Jun  9 10:15:34 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 10:15:34 GMT
Subject: RFR: 8288023: AArch64: disable PAC-RET when preview is enabled
In-Reply-To: <Tg272yZbqb3jr9ybXvwJ6_gz8v8akPOBAcp4DqhmAV8=.0612d782-fe64-4e78-8a13-fcd017d81b55@github.com>
References: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
 <Tg272yZbqb3jr9ybXvwJ6_gz8v8akPOBAcp4DqhmAV8=.0612d782-fe64-4e78-8a13-fcd017d81b55@github.com>
Message-ID: <GN17OvOGoyShAM4_VSWsxsnT4PKt5w3odJzBVElRey0=.5067dbbb-d42f-42d5-9536-4c511654a55b@github.com>

On Thu, 9 Jun 2022 09:48:55 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> @nick-arm If you integrate over the next couple of hours this will make it in before the 19 fork.

OK sure. I'll just wait for the GHA tests to finish.

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

PR: https://git.openjdk.java.net/jdk/pull/9102

From duke at openjdk.java.net  Thu Jun  9 10:30:41 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 9 Jun 2022 10:30:41 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v2]
In-Reply-To: <1e9QiLAFJUcvVzdleg9aeWTb4V7_SjL3NaGeQqiAJaw=.bc3a136d-3570-4eac-9b9c-c93cc4b71f62@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <1e9QiLAFJUcvVzdleg9aeWTb4V7_SjL3NaGeQqiAJaw=.bc3a136d-3570-4eac-9b9c-c93cc4b71f62@github.com>
Message-ID: <msi4Q9Uk1DJNXHO7av6I8nW2j5nIignxVKMdP02mZzs=.ee41872a-9a95-486f-b2c7-5ecbe7741d46@github.com>

On Thu, 9 Jun 2022 09:24:20 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
>> 
>> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
>> 
>> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
>> 
>> Example. Dummy method disassembly on AARCH, before vs after:
>> 
>> [Verified Entry Point]                          |  [Verified Entry Point]
>>   78c63b80:   nop                               |    7437e480:   nop
>>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>>   78c63ba0:   .inst   0x00000000 ; undefined    |
>>   78c63ba4:   .inst   0x00000000 ; undefined    |
>>   78c63ba8:   .inst   0x00000000 ; undefined    |
>>   78c63bac:   .inst   0x00000000 ; undefined    |
>>   78c63bb0:   .inst   0x00000000 ; undefined    |
>>   78c63bb4:   .inst   0x00000000 ; undefined    |
>>   78c63bb8:   .inst   0x00000000 ; undefined    |
>>   78c63bbc:   .inst   0x00000000 ; undefined    |
>> [Stub Code]                                     |  [Stub Code]
>>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
>> [Exception Handler]                             |  [Exception Handler]
>>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
>> [Deopt Handler Code]                            |  [Deopt Handler Code]
>>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup and comments

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 668:

> 666:   assert((CodeBuffer::SECT_INSTS == CodeBuffer::SECT_STUBS - 1) &&
> 667:          (CodeBuffer::SECT_CONSTS == CodeBuffer::SECT_INSTS - 1), "sections order: consts, insts, stubs");
> 668:   // buffer content: [contants + code_align] + [code + stubs_align] + [stubs]

A typo in '[contants'. Should be '[constants'

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

PR: https://git.openjdk.java.net/jdk/pull/8453

From duke at openjdk.java.net  Thu Jun  9 11:43:20 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 9 Jun 2022 11:43:20 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v7]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <7-2t69yODmdX6wUiOQHq7LzAEKNCCG5k7Rq6NcGMkfY=.4883470c-c460-45f3-b456-a0a38eedeef7@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/1eddf482..f89bab4a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Thu Jun  9 11:43:20 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 9 Jun 2022 11:43:20 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v6]
In-Reply-To: <MtYpoHixn6XH46Gne8T-KKyE__ZoIwE_hFDAuN_lxfQ=.cbf97003-eaa9-4bd0-a831-8d9149128a6a@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <-sL23oWJQGg6b54V_s_MTxoJC-VpH4qERBKm8cuRssw=.8c2377a5-4de6-4ef9-8f09-ecee7a8c654d@github.com>
 <MtYpoHixn6XH46Gne8T-KKyE__ZoIwE_hFDAuN_lxfQ=.cbf97003-eaa9-4bd0-a831-8d9149128a6a@github.com>
Message-ID: <mtzOnsVoCY0q6zzqoWKDgKKzrz4gnWXmE7JAmvfrUnc=.6e2ec16d-f71d-40cd-b43c-20885056821b@github.com>

On Wed, 8 Jun 2022 17:26:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify code
>>  - Refactor using LogStream
>
> src/hotspot/share/runtime/deoptimization.hpp line 172:
> 
>> 170: 
>> 171:     // Does the actual work for deoptimizing a single frame
>> 172:     static void deoptimize_single_frame(JavaThread* thread, frame fr, DeoptReason reason);
> 
> Please, keep original indent for this lines to match other line around. Actually `private:` has wrong additional space.

Thank you! The additional indent on `private:` misled me :-), fixing that too.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From mbaesken at openjdk.java.net  Thu Jun  9 11:47:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 9 Jun 2022 11:47:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
Message-ID: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>

We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.

Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
VALID_VS_VERSIONS="2019 2017 2022"
Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

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

Commit messages:
 - JDK-8288094

Changes: https://git.openjdk.java.net/jdk/pull/9105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288094
  Stats: 144 lines in 9 files changed: 0 ins; 131 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.java.net/jdk/pull/9105

From ngasson at openjdk.java.net  Thu Jun  9 11:52:40 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 11:52:40 GMT
Subject: Integrated: 8288023: AArch64: disable PAC-RET when preview is enabled
In-Reply-To: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
References: <xaCk8fIxAvXu90i0gHK7hZi7aV_3EaRihQ8CSsabtzk=.09e1bce3-fde2-44e9-bb85-1f8e020a290e@github.com>
Message-ID: <17WaB7DtcmY01bahek8YvqYEzJo19NCgGktHTBHmZmI=.78f765d3-b93f-46f4-a059-85042391a4f9@github.com>

On Thu, 9 Jun 2022 08:26:38 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> PAC-RET is not currently compatible with the continuation freeze/thaw mechanism used by virtual threads, and additionally
> `-XX:UseBranchProtection=pac-ret` enables `PreserveFramePointer` which prevents the use of the continuation thaw fast-path (about 15% slower for the "Skynet" JMH benchmark).  So for now just disable PAC when `--enable-preview` was also passed.
> 
> See some earlier discussion here: #9067

This pull request has now been integrated.

Changeset: 4285e3d6
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4285e3d6db487d85138486d1f7853c7c067c59cd
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8288023: AArch64: disable PAC-RET when preview is enabled

Reviewed-by: rpressler, adinn

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

PR: https://git.openjdk.java.net/jdk/pull/9102

From ngasson at openjdk.java.net  Thu Jun  9 11:58:37 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 11:58:37 GMT
Subject: RFR: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <yFHofJnPlnJP6LpyO-3bu9Uy94Ujvobay4BRRkz3CS8=.0c18f112-f07e-4e1a-ab1f-e8fc8558a58a@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

Zero works as well, as does any other value that's the same at function entry/exit. But the disadvantage of zero is that you get the same authentication code for each call to the function, whereas using SP gives you different codes as long as the stack depth is different.

I'll close this one for now.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From ngasson at openjdk.java.net  Thu Jun  9 11:58:37 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 9 Jun 2022 11:58:37 GMT
Subject: Withdrawn: 8287325: AArch64: fix virtual threads with
 -XX:UseBranchProtection=pac-ret
In-Reply-To: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
References: <Ve9dEtTkhZEMtEDS-grT-SKbBwuoR5p-ydGUh9y7iF0=.e7e2893c-3c9f-4ef7-9870-00fd23004650@github.com>
Message-ID: <hZ9TnFR7elvMrbH9L7hJH_3hiu8eKKtWnClIxlWVnSo=.3ef6c4b4-3782-4940-ba5c-33bbcebe9e42@github.com>

On Tue, 7 Jun 2022 16:42:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The continuation free/thaw mechanism relies on being able to move thread stacks around in memory.  However when PAC is enabled on supported AArch64 CPUs, the saved LR on the stack contains a "pointer authentication code" signed with the stack pointer at the time the frame was created.  When a stack frame is relocated we need to re-sign the LR with the new stack pointer to ensure it authenticates successfully when the method returns.
> 
> Introduced `ContinuationHelper::return_pc_at()` to avoid directly reading the saved PC from the stack in shared code.  On AArch64 with PAC it enabled it strips the PAC from the address after reading it, on all other platforms it just loads the PC from the stack as before.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/9067

From tanksherman27 at gmail.com  Thu Jun  9 12:03:51 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 9 Jun 2022 20:03:51 +0800
Subject: Build failures after 8214976
Message-ID: <CAP2b4GMk+1zczwxzOkpNQ99=ZB-B8OZ54=C=2nJLjOe7igtJng@mail.gmail.com>

After 8214976 builds on my local device seem to be failing when the
precompiled headers are being generated, and I'm somewhat stumped by what
seems to be causing them. Has anyone else faced this issue besides me? The
failure log is below, in case that helps

/src/hotspot/share/utilities/globalDefinitions.hpp:169:23: error:
conflicting declaration of 'int vsprintf(char*, const char*, va_list)' with
'C' linkage
  169 | FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use
os::vsnprintf");

/src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
definition of macro 'FORBID_C_FUNCTION'
   82 |   extern "C" __attribute__((__warning__(alternative))) signature;

stdio.h:423:5: note: previous declaration with 'C++' linkage
  423 | int vsprintf (char *__stream, const char *__format,
__builtin_va_list __local_argv)

/src/hotspot/share/utilities/globalDefinitions.hpp:170:23: error:
conflicting declaration of 'int vsnprintf(char*, size_t, const char*,
va_list)' with 'C' linkage
  170 | FORBID_C_FUNCTION(int vsnprintf(char*, size_t, const char*,
va_list), "use os::vsnprintf");

/src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
definition of macro 'FORBID_C_FUNCTION'
   82 |   extern "C" __attribute__((__warning__(alternative))) signature;
      |                                                        ^~~~~~~~~

stdio.h:464:5: note: previous declaration with 'C++' linkage
  464 | int vsnprintf (char *__stream, size_t __n, const char *__format,
__builtin_va_list __local_argv)

best regards,
Julian

From duke at openjdk.java.net  Thu Jun  9 12:28:28 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 9 Jun 2022 12:28:28 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.346s][info][deoptimization] Deoptimization start {
> [1.346s][info][deoptimization]   compileId = 407
> [1.346s][info][deoptimization]   compiler = c2
> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
> [1.346s][info][deoptimization]   instruction = ifne
> [1.346s][info][deoptimization]   reason = unstable_if
> [1.346s][info][deoptimization]   action = reinterpret
> [1.346s][info][deoptimization] } Deoptimization end

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Fix printing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8812/files
  - new: https://git.openjdk.java.net/jdk/pull/8812/files/f89bab4a..130a3a6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=06-07

  Stats: 9 lines in 1 file changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Thu Jun  9 12:28:31 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 9 Jun 2022 12:28:31 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v7]
In-Reply-To: <7-2t69yODmdX6wUiOQHq7LzAEKNCCG5k7Rq6NcGMkfY=.4883470c-c460-45f3-b456-a0a38eedeef7@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <7-2t69yODmdX6wUiOQHq7LzAEKNCCG5k7Rq6NcGMkfY=.4883470c-c460-45f3-b456-a0a38eedeef7@github.com>
Message-ID: <hkFzxIc_9NZNNl0wG9WKmWKQKue8Y0ty5UfTA1awe-w=.0dd5a90f-8820-45d0-b99f-94e7b1bdc1a6@github.com>

On Thu, 9 Jun 2022 11:43:20 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Current log line:

`[1.334s][debug][deoptimization] cid=206 level=4 java.util.concurrent.locks.ReentrantLock$Sync::tryRelease trap_bci=26 unstable_if reinterpret pc=0x00007f89dcbf4954 relative_pc=0x0000000000000154`

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From duke at openjdk.java.net  Thu Jun  9 12:28:34 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 9 Jun 2022 12:28:34 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v6]
In-Reply-To: <MtYpoHixn6XH46Gne8T-KKyE__ZoIwE_hFDAuN_lxfQ=.cbf97003-eaa9-4bd0-a831-8d9149128a6a@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <-sL23oWJQGg6b54V_s_MTxoJC-VpH4qERBKm8cuRssw=.8c2377a5-4de6-4ef9-8f09-ecee7a8c654d@github.com>
 <MtYpoHixn6XH46Gne8T-KKyE__ZoIwE_hFDAuN_lxfQ=.cbf97003-eaa9-4bd0-a831-8d9149128a6a@github.com>
Message-ID: <OUvFORgcMoqM4vux5Y0atICrCX9Y2H2MoTAHCNln5Sk=.da9b88d6-f241-4990-ac91-cabb345bd0c2@github.com>

On Wed, 8 Jun 2022 17:36:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>I may be was not clear but do not use % for OSR marking.

My bad, I misunderstood you.

>Please, print pc and relative_pc at the end of output.

Fixed.

> src/hotspot/share/runtime/deoptimization.cpp line 1852:
> 
>> 1850:     nm->method()->print_short_name(&ls);
>> 1851:     ls.print(" @ ");
>> 1852:     ls.print("%d ", trap_bci);
> 
> Instead of `@ %d` please use same pattern: `trap_bci=%d`.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8812

From martin.doerr at sap.com  Thu Jun  9 12:33:45 2022
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 9 Jun 2022 12:33:45 +0000
Subject: Build failures after 8214976
In-Reply-To: <CAP2b4GMk+1zczwxzOkpNQ99=ZB-B8OZ54=C=2nJLjOe7igtJng@mail.gmail.com>
References: <CAP2b4GMk+1zczwxzOkpNQ99=ZB-B8OZ54=C=2nJLjOe7igtJng@mail.gmail.com>
Message-ID: <AS8PR02MB85442575B799C26CE5B32B829AA79@AS8PR02MB8544.eurprd02.prod.outlook.com>

Hi Julian,

I have already filed an issue related to that change:
https://bugs.openjdk.org/browse/JDK-8288101

Does the build work when using configure flag --disable-warnings-as-errors ?
Or is it an additional problem?
Which compiler version are you using?

Best regards,
Martin

Von: hotspot-dev <hotspot-dev-retn at openjdk.java.net> im Auftrag von Julian Waters <tanksherman27 at gmail.com>
Datum: Donnerstag, 9. Juni 2022 um 14:04
An: hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>
Betreff: Build failures after 8214976

After 8214976 builds on my local device seem to be failing when the
precompiled headers are being generated, and I'm somewhat stumped by what
seems to be causing them. Has anyone else faced this issue besides me? The
failure log is below, in case that helps

/src/hotspot/share/utilities/globalDefinitions.hpp:169:23: error:
conflicting declaration of 'int vsprintf(char*, const char*, va_list)' with
'C' linkage
  169 | FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use
os::vsnprintf");

/src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
definition of macro 'FORBID_C_FUNCTION'
   82 |   extern "C" __attribute__((__warning__(alternative))) signature;

stdio.h:423:5: note: previous declaration with 'C++' linkage
  423 | int vsprintf (char *__stream, const char *__format,
__builtin_va_list __local_argv)

/src/hotspot/share/utilities/globalDefinitions.hpp:170:23: error:
conflicting declaration of 'int vsnprintf(char*, size_t, const char*,
va_list)' with 'C' linkage
  170 | FORBID_C_FUNCTION(int vsnprintf(char*, size_t, const char*,
va_list), "use os::vsnprintf");

/src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
definition of macro 'FORBID_C_FUNCTION'
   82 |   extern "C" __attribute__((__warning__(alternative))) signature;
      |                                                        ^~~~~~~~~

stdio.h:464:5: note: previous declaration with 'C++' linkage
  464 | int vsnprintf (char *__stream, size_t __n, const char *__format,
__builtin_va_list __local_argv)

best regards,
Julian

From tanksherman27 at gmail.com  Thu Jun  9 12:39:36 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Thu, 9 Jun 2022 20:39:36 +0800
Subject: Build failures after 8214976
In-Reply-To: <AS8PR02MB85442575B799C26CE5B32B829AA79@AS8PR02MB8544.eurprd02.prod.outlook.com>
References: <CAP2b4GMk+1zczwxzOkpNQ99=ZB-B8OZ54=C=2nJLjOe7igtJng@mail.gmail.com>
 <AS8PR02MB85442575B799C26CE5B32B829AA79@AS8PR02MB8544.eurprd02.prod.outlook.com>
Message-ID: <CAP2b4GN8gda+g7DLe8eXGvm52uwv2hoFstv8GmPUMgv43dNT0g@mail.gmail.com>

Hi Martin,

I've yet to try passing the --disable-warnings-as-errors flag yet, for the
time being I disabled the macro so I could test my local branch. I'll try
doing that later, thanks for the heads up. I'm using gcc version 11.2 at
the moment, if that's important.

best regards,
Julian

On Thu, Jun 9, 2022 at 8:33 PM Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi Julian,
>
>
>
> I have already filed an issue related to that change:
>
> https://bugs.openjdk.org/browse/JDK-8288101
>
>
>
> Does the build work when using configure flag
> --disable-warnings-as-errors ?
>
> Or is it an additional problem?
>
> Which compiler version are you using?
>
>
>
> Best regards,
>
> Martin
>
>
>
> *Von: *hotspot-dev <hotspot-dev-retn at openjdk.java.net> im Auftrag von
> Julian Waters <tanksherman27 at gmail.com>
> *Datum: *Donnerstag, 9. Juni 2022 um 14:04
> *An: *hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>
> *Betreff: *Build failures after 8214976
>
> After 8214976 builds on my local device seem to be failing when the
> precompiled headers are being generated, and I'm somewhat stumped by what
> seems to be causing them. Has anyone else faced this issue besides me? The
> failure log is below, in case that helps
>
> /src/hotspot/share/utilities/globalDefinitions.hpp:169:23: error:
> conflicting declaration of 'int vsprintf(char*, const char*, va_list)' with
> 'C' linkage
>   169 | FORBID_C_FUNCTION(int vsprintf(char*, const char*, va_list), "use
> os::vsnprintf");
>
> /src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
> definition of macro 'FORBID_C_FUNCTION'
>    82 |   extern "C" __attribute__((__warning__(alternative))) signature;
>
> stdio.h:423:5: note: previous declaration with 'C++' linkage
>   423 | int vsprintf (char *__stream, const char *__format,
> __builtin_va_list __local_argv)
>
> /src/hotspot/share/utilities/globalDefinitions.hpp:170:23: error:
> conflicting declaration of 'int vsnprintf(char*, size_t, const char*,
> va_list)' with 'C' linkage
>   170 | FORBID_C_FUNCTION(int vsnprintf(char*, size_t, const char*,
> va_list), "use os::vsnprintf");
>
> /src/hotspot/share/utilities/compilerWarnings_gcc.hpp:82:56: note: in
> definition of macro 'FORBID_C_FUNCTION'
>    82 |   extern "C" __attribute__((__warning__(alternative))) signature;
>       |                                                        ^~~~~~~~~
>
> stdio.h:464:5: note: previous declaration with 'C++' linkage
>   464 | int vsnprintf (char *__stream, size_t __n, const char *__format,
> __builtin_va_list __local_argv)
>
> best regards,
> Julian
>

From aph at openjdk.java.net  Thu Jun  9 13:16:42 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 9 Jun 2022 13:16:42 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v4]
In-Reply-To: <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
Message-ID: <P_Lyenh_v47WqWlGvMzhPzUOo26XpXqsON0A3PrU0VE=.99544c72-96a4-4bc5-a0a1-08c646017c60@github.com>

On Wed, 8 Jun 2022 09:36:42 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
>> 
>> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
>> 
>> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
>> 
>> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
>> 
>> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
>> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
>> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
>> 
>> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.
>
> Dmitry Chuyko 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:
> 
>  - Removed unnecessary changes (forced UseLSE, blank lines)
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>  - Revert "hardlse feature"
>    
>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>  - Merge branch 'openjdk:master' into JDK-8282322
>  - hardlse feature

src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 283:

> 281: aarch64_atomic_cmpxchg_8_relaxed_default_impl:
> 282: #ifdef __ARM_FEATURE_ATOMICS
> 283:         prfm    pstl1strm, [x0]

Here too.

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

PR: https://git.openjdk.java.net/jdk/pull/8779

From ysuenaga at openjdk.java.net  Thu Jun  9 13:19:31 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Jun 2022 13:19:31 GMT
Subject: RFR: 8288048: Build failure with GCC 6 after JDK-8286562
In-Reply-To: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
References: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
Message-ID: <n-aW5zRK0rd9pqrDv8PA8FpVpvULenzLM0Ff0BmVE5w=.4dbe6616-a263-4070-8c0a-71260645e971@github.com>

On Wed, 8 Jun 2022 17:52:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug` build with GCC 6
>  - [x] Linux x86_64 `fastdebug` build with GCC 9
> 
> @YaSuenag, if you could test with GCC 12, that would be helpful.

Your change works fine with GCC 12.1.1 on my Fedora 36 (gcc-12.1.1-1.fc36.x86_64).
Looks good.

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

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9090

From shade at openjdk.java.net  Thu Jun  9 14:10:14 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 14:10:14 GMT
Subject: RFR: 8288048: Build failure with GCC 6 after JDK-8286562
In-Reply-To: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
References: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
Message-ID: <KtCgTKAp61LpZ4o9pztbo5qtdP9rDm6Mr5nAEugdKe8=.7e4ba59c-adf6-48d6-9c04-b65ed98b28d2@github.com>

On Wed, 8 Jun 2022 17:52:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug` build with GCC 6
>  - [x] Linux x86_64 `fastdebug` build with GCC 9
> 
> @YaSuenag, if you could test with GCC 12, that would be helpful.

Thanks! I am integrating to unbreak JDK 19 on GCC 6 before RDP1 hits.

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

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

From shade at openjdk.java.net  Thu Jun  9 14:19:52 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Jun 2022 14:19:52 GMT
Subject: Integrated: 8288048: Build failure with GCC 6 after JDK-8286562
In-Reply-To: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
References: <9ZmNDEj3PSeCvcuikHzcJOAvvN7P2O7bVluhjSM0WrE=.a9182dc2-2eeb-4a30-ace8-6f9cc417e36c@github.com>
Message-ID: <K9GfS5o-tihUZYFSun9i9pXx3oQfWqe0SoFfWZGJLYQ=.dad99c0c-8a1c-4ee0-be8f-25c67fd63569@github.com>

On Wed, 8 Jun 2022 17:52:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8286562](https://bugs.openjdk.org/browse/JDK-8286562) added the `-Wstringop-overflow` pragma, which cannot be understood by GCC 6. There are already ways to make such pragmas conditional on GCC version.
> 
> Additional testing:
>  - [x] Linux x86_64 `fastdebug` build with GCC 6
>  - [x] Linux x86_64 `fastdebug` build with GCC 9
> 
> @YaSuenag, if you could test with GCC 12, that would be helpful.

This pull request has now been integrated.

Changeset: 59b0de6b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59b0de6bc7064b39cdc51517dee4f4d96af3efaf
Stats:     11 lines in 3 files changed: 10 ins; 0 del; 1 mod

8288048: Build failure with GCC 6 after JDK-8286562

Reviewed-by: kbarrett, ysuenaga

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

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

From bulasevich at openjdk.java.net  Thu Jun  9 14:45:36 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 14:45:36 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

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

  typo fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8453/files
  - new: https://git.openjdk.org/jdk/pull/8453/files/43a69437..630f9c9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=01-02

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

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

From bulasevich at openjdk.java.net  Thu Jun  9 14:45:39 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 14:45:39 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <yfcRX9IqPYcHa6eMZSSqzN7fgLSoG8RjoD491nQ7B7M=.01be737d-f692-463a-92e2-cfb711e596e2@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <yfcRX9IqPYcHa6eMZSSqzN7fgLSoG8RjoD491nQ7B7M=.01be737d-f692-463a-92e2-cfb711e596e2@github.com>
Message-ID: <M-feOni5DvX3Jf4cDBWx7e0UuSREu1FY8uOxh1H0gdk=.c763e855-552b-46d6-987d-8c097e954531@github.com>

On Wed, 4 May 2022 15:52:19 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo fix
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 40:
> 
>> 38: 
>> 39: define_pd_global(uintx, CodeCacheSegmentSize,    64 COMPILER1_AND_COMPILER2_PRESENT(+64)); // Tiered compilation has large code-entry alignment.
>> 40: define_pd_global(intx, CodeEntryAlignment,       64);
> 
> This change looks reasonable to me. I found the following in the N1 Opt Guide:
> 
> Consider aligning subroutine entry points and branch targets to 32B boundaries, within the bounds of the code-density requirements of the program. This will ensure that the subsequent fetch can maximize bandwidth following the taken branch by bringing in all useful instructions

I have rolled back CodeEntryAlignment 64->32 change as it shows different results on ARM platforms. I think it should be done in a separate PR. It can be tuned in vm_version after CPU architecture check.

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

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

From bulasevich at openjdk.java.net  Thu Jun  9 14:45:42 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 14:45:42 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v2]
In-Reply-To: <msi4Q9Uk1DJNXHO7av6I8nW2j5nIignxVKMdP02mZzs=.ee41872a-9a95-486f-b2c7-5ecbe7741d46@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <1e9QiLAFJUcvVzdleg9aeWTb4V7_SjL3NaGeQqiAJaw=.bc3a136d-3570-4eac-9b9c-c93cc4b71f62@github.com>
 <msi4Q9Uk1DJNXHO7av6I8nW2j5nIignxVKMdP02mZzs=.ee41872a-9a95-486f-b2c7-5ecbe7741d46@github.com>
Message-ID: <rc_5F288NvhtlSRyIdHx7Fz1g8azX6Pm_RMXFi1C1-Q=.8133efbd-7305-4e49-ae2c-0376349836d2@github.com>

On Thu, 9 Jun 2022 10:26:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup and comments
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 668:
> 
>> 666:   assert((CodeBuffer::SECT_INSTS == CodeBuffer::SECT_STUBS - 1) &&
>> 667:          (CodeBuffer::SECT_CONSTS == CodeBuffer::SECT_INSTS - 1), "sections order: consts, insts, stubs");
>> 668:   // buffer content: [contants + code_align] + [code + stubs_align] + [stubs]
> 
> A typo in '[contants'. Should be '[constants'

thanks

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

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

From duke at openjdk.java.net  Thu Jun  9 14:54:33 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 9 Jun 2022 14:54:33 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
Message-ID: <rO7lge9H64rQWXUoaWHdndjNSz9_YBVxveblFeqO1iA=.f1509bb1-5317-4789-a166-37ebf135a0e1@github.com>

On Thu, 9 Jun 2022 14:45:36 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
>> 
>> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
>> 
>> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
>> 
>> Example. Dummy method disassembly on AARCH, before vs after:
>> 
>> [Verified Entry Point]                          |  [Verified Entry Point]
>>   78c63b80:   nop                               |    7437e480:   nop
>>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>>   78c63ba0:   .inst   0x00000000 ; undefined    |
>>   78c63ba4:   .inst   0x00000000 ; undefined    |
>>   78c63ba8:   .inst   0x00000000 ; undefined    |
>>   78c63bac:   .inst   0x00000000 ; undefined    |
>>   78c63bb0:   .inst   0x00000000 ; undefined    |
>>   78c63bb4:   .inst   0x00000000 ; undefined    |
>>   78c63bb8:   .inst   0x00000000 ; undefined    |
>>   78c63bbc:   .inst   0x00000000 ; undefined    |
>> [Stub Code]                                     |  [Stub Code]
>>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
>> [Exception Handler]                             |  [Exception Handler]
>>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
>> [Deopt Handler Code]                            |  [Deopt Handler Code]
>>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo fix

lgtm

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

Marked as reviewed by eastig at github.com (no known OpenJDK username).

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

From bulasevich at openjdk.java.net  Thu Jun  9 14:54:36 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Thu, 9 Jun 2022 14:54:36 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <yM94XeIUXEAdBzl_le852snfLAnMP_OhWayHaPGyNqU=.f787e462-daab-4538-95be-7b20be83c697@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <yM94XeIUXEAdBzl_le852snfLAnMP_OhWayHaPGyNqU=.f787e462-daab-4538-95be-7b20be83c697@github.com>
Message-ID: <QMCbME5nLkOvm2emCdtwo2D23gU7FkzOy5dSOvxsCU4=.99934ca8-18d4-4e06-9c0f-a98e1cdf630d@github.com>

On Tue, 7 Jun 2022 22:23:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo fix
>
> test/hotspot/jtreg/compiler/jvmci/errors/TestInvalidCompilationResult.java line 88:
> 
>> 86:     }
>> 87: 
>> 88:     static final int validDataSectionAlignment = 8;
> 
> Add comment to explain where 8 comes from.

fixed. thanks!

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

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

From kvn at openjdk.java.net  Thu Jun  9 17:35:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 9 Jun 2022 17:35:14 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
Message-ID: <CrTKpzVxhXKSViOV4KDTk8uWcoko2qK9aAXG4_1sYYU=.67df2413-b040-40a9-80e6-178d8f5e6569@github.com>

On Thu, 9 Jun 2022 12:28:28 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix printing

Looks good.
I don't see GHA testing. What testing you did? I will run tier1 in our system to see if it build on all our systems.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Thu Jun  9 18:00:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 9 Jun 2022 18:00:09 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
Message-ID: <zC8Qi3AkZrRlR4GkE59kQPqWPO6vCNUDncWROZLGCUA=.01aee97b-efaa-4973-8384-b2012a80e25e@github.com>

On Thu, 9 Jun 2022 12:28:28 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix printing

I noticed that method name is missing signature (arguments type) which we have in `TraceDeoptimization` output:

UNCOMMON TRAP method=java.util.Properties.getProperty(Ljava/lang/String;)Ljava/lang/String;  bci=10 pc=0x00007fbae0c23a94, relative_pc=0x00000000000000b4, debug_id=0 compiler=c2 compile_id=9 (@0x00007fbae0c23a94) thread=2203929 reason=null_check action=make_not_entrant unloaded_class_index=-1 debug_id=0

Yes, `PrintCompilation` does not have it but it would be nice to have it in this output.

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

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

From kvn at openjdk.java.net  Thu Jun  9 18:08:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 9 Jun 2022 18:08:07 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
Message-ID: <XQ_hPnSxUxvIgLffO-lwFpoBfWFeqNVM1YfHxg623ss=.c8030b23-3762-41b7-aab9-47db5332fd72@github.com>

On Thu, 9 Jun 2022 12:28:28 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix printing

Please, also update the output example in PR's description. It is misleading now.

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

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

From mdoerr at openjdk.java.net  Thu Jun  9 18:32:22 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 9 Jun 2022 18:32:22 GMT
Subject: RFR: 8288101: False build warning-as-error with GCC 9 after
 JDK-8214976
In-Reply-To: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
References: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
Message-ID: <isX9Hi-ogqNz1LsEzLAwOdudxnUYrLQCODYDTVh7yXQ=.95e6098a-0b56-4bd8-8f92-bb70fce4b07f@github.com>

On Thu, 9 Jun 2022 16:35:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> gcc version 9.4.0 (also 9.3.1) produces build warning after [JDK-8214976](https://bugs.openjdk.org/browse/JDK-8214976):
> 
> 
> os_posix.cpp:786:34: error: call to 'exit' declared with attribute warning: use os::exit [-Werror=attribute-warning]
>   786 | ALLOW_C_FUNCTION(::exit, ::exit(num);)
>       | ~~~~~~^~~~~
> 
> 
> Apparently, GCC 9 has a bug with nesting pragmas. The [Godbolt experiments](https://godbolt.org/z/vonsqEnK6) show this only affects GCC 9, and there are no easy way to restructure the macros to dodge this, so the way out to bump the requirement for new macros to GCC >= 10.
> 
> Additional testing:
>  - [x] Linux x86_64 build with GCC 9.4.0 (now passes without warnings)
>  - [ ] Linux x86_64 build with GCC 10.2.1 (still passes)

Thanks for fixing it! LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/1

From zgu at openjdk.java.net  Thu Jun  9 19:20:19 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 9 Jun 2022 19:20:19 GMT
Subject: RFR: 8288101: False build warning-as-error with GCC 9 after
 JDK-8214976
In-Reply-To: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
References: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
Message-ID: <iS3qgzpnBK17BGQ0FgCOjx-yrUnzkTaDRbnmhmuY9ZE=.d2709b93-a783-437c-b365-86dec11402b1@github.com>

On Thu, 9 Jun 2022 16:35:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> gcc version 9.4.0 (also 9.3.1) produces build warning after [JDK-8214976](https://bugs.openjdk.org/browse/JDK-8214976):
> 
> 
> os_posix.cpp:786:34: error: call to 'exit' declared with attribute warning: use os::exit [-Werror=attribute-warning]
>   786 | ALLOW_C_FUNCTION(::exit, ::exit(num);)
>       | ~~~~~~^~~~~
> 
> 
> Apparently, GCC 9 has a bug with nesting pragmas. The [Godbolt experiments](https://godbolt.org/z/vonsqEnK6) show this only affects GCC 9, and there are no easy way to restructure the macros to dodge this, so the way out to bump the requirement for new macros to GCC >= 10.
> 
> Additional testing:
>  - [x] Linux x86_64 build with GCC 9.4.0 (now passes without warnings)
>  - [x] Linux x86_64 build with GCC 10.2.1 (still passes)

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/1

From kbarrett at openjdk.java.net  Thu Jun  9 20:28:27 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 9 Jun 2022 20:28:27 GMT
Subject: RFR: 8288101: False build warning-as-error with GCC 9 after
 JDK-8214976
In-Reply-To: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
References: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
Message-ID: <iyLEdR4hzxYm7sOAZj55Mf9Nw-5nPyAsWm60HM8Jypw=.1762b056-7178-4232-abbc-2e9e450a66d5@github.com>

On Thu, 9 Jun 2022 16:35:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> gcc version 9.4.0 (also 9.3.1) produces build warning after [JDK-8214976](https://bugs.openjdk.org/browse/JDK-8214976):
> 
> 
> os_posix.cpp:786:34: error: call to 'exit' declared with attribute warning: use os::exit [-Werror=attribute-warning]
>   786 | ALLOW_C_FUNCTION(::exit, ::exit(num);)
>       | ~~~~~~^~~~~
> 
> 
> Apparently, GCC 9 has a bug with nesting pragmas. The [Godbolt experiments](https://godbolt.org/z/vonsqEnK6) show this only affects GCC 9, and there are no easy way to restructure the macros to dodge this, so the way out to bump the requirement for new macros to GCC >= 10.
> 
> Additional testing:
>  - [x] Linux x86_64 build with GCC 9.4.0 (now passes without warnings)
>  - [x] Linux x86_64 build with GCC 10.2.1 (still passes)

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/1

From xliu at openjdk.java.net  Thu Jun  9 22:15:02 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 9 Jun 2022 22:15:02 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v7]
In-Reply-To: <hkFzxIc_9NZNNl0wG9WKmWKQKue8Y0ty5UfTA1awe-w=.0dd5a90f-8820-45d0-b99f-94e7b1bdc1a6@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <7-2t69yODmdX6wUiOQHq7LzAEKNCCG5k7Rq6NcGMkfY=.4883470c-c460-45f3-b456-a0a38eedeef7@github.com>
 <hkFzxIc_9NZNNl0wG9WKmWKQKue8Y0ty5UfTA1awe-w=.0dd5a90f-8820-45d0-b99f-94e7b1bdc1a6@github.com>
Message-ID: <Yp9eBam_-SvlFpl13RbsWJcOc6vn5f-nSwn3HSb4-K4=.5c102ca7-c6a1-4dbc-9a15-c3b7b64885fa@github.com>

On Thu, 9 Jun 2022 12:23:12 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> Current log line:
> 
> `[1.334s][debug][deoptimization] cid=206 level=4 java.util.concurrent.locks.ReentrantLock$Sync::tryRelease trap_bci=26 unstable_if reinterpret pc=0x00007f89dcbf4954 relative_pc=0x0000000000000154`

hi, @jdksjolen , 
Could you update PR description example?  It looks like you have changed it to a one-liner.  just for a record in case we need to revisit this PR.  

Do you consider 'deopt' instead of 'deoptimization'? I feel deoptimization is too long as a tag.  Neither of them is a word anyway. :)

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

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

From xliu at openjdk.java.net  Thu Jun  9 22:25:03 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 9 Jun 2022 22:25:03 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
Message-ID: <G-EwHFb0ktFmCvXQC2dOytWCg75ioWN6xnLJb5n86ng=.3c13c013-cdcd-46e7-bde9-5580494303cd@github.com>

On Thu, 9 Jun 2022 12:28:28 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.346s][info][deoptimization] Deoptimization start {
>> [1.346s][info][deoptimization]   compileId = 407
>> [1.346s][info][deoptimization]   compiler = c2
>> [1.346s][info][deoptimization]   method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26
>> [1.346s][info][deoptimization]   instruction = ifne
>> [1.346s][info][deoptimization]   reason = unstable_if
>> [1.346s][info][deoptimization]   action = reinterpret
>> [1.346s][info][deoptimization] } Deoptimization end
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix printing

src/hotspot/share/runtime/deoptimization.cpp line 1858:

> 1856:     ls.print("pc=" INTPTR_FORMAT " relative_pc=" INTPTR_FORMAT,
> 1857:              pc, fr.pc() - nm->code_begin());
> 1858:     ls.cr();

nits:  you can combine this with print_cr(). 
you can move `is_osr` in if (lt.is_enabled()) block.

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

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

From kvn at openjdk.java.net  Fri Jun 10 00:00:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 10 Jun 2022 00:00:08 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
Message-ID: <LVr4juDokZ9LcUPyuERyRMpmVVsCyeyte5GuWi4F7x8=.f8bb4eef-3ceb-4268-a119-273294e5d0a3@github.com>

On Thu, 9 Jun 2022 14:45:36 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
>> 
>> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
>> 
>> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
>> 
>> Example. Dummy method disassembly on AARCH, before vs after:
>> 
>> [Verified Entry Point]                          |  [Verified Entry Point]
>>   78c63b80:   nop                               |    7437e480:   nop
>>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>>   78c63ba0:   .inst   0x00000000 ; undefined    |
>>   78c63ba4:   .inst   0x00000000 ; undefined    |
>>   78c63ba8:   .inst   0x00000000 ; undefined    |
>>   78c63bac:   .inst   0x00000000 ; undefined    |
>>   78c63bb0:   .inst   0x00000000 ; undefined    |
>>   78c63bb4:   .inst   0x00000000 ; undefined    |
>>   78c63bb8:   .inst   0x00000000 ; undefined    |
>>   78c63bbc:   .inst   0x00000000 ; undefined    |
>> [Stub Code]                                     |  [Stub Code]
>>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
>> [Exception Handler]                             |  [Exception Handler]
>>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
>> [Deopt Handler Code]                            |  [Deopt Handler Code]
>>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo fix

Looks good. I will test it before approval.

test/hotspot/jtreg/compiler/jvmci/errors/TestInvalidCompilationResult.java line 88:

> 86:     }
> 87: 
> 88:     // DataSectionAlignment value matches the alignment of the CodeBuffer::SECT_CONSTS code section

`the alignment sizeof(jdouble) of the`

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

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

From sviswanathan at openjdk.java.net  Fri Jun 10 00:09:00 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 10 Jun 2022 00:09:00 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
Message-ID: <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>

On Wed, 8 Jun 2022 09:39:04 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:
> 
>                                                     Before          After
>     Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
>     Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
>     Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op

@merykitty Could you please also add the micro benchmark where compareUnsigned result is stored directly in an integer and show the performance of that?

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

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

From kvn at openjdk.java.net  Fri Jun 10 01:36:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 10 Jun 2022 01:36:05 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>

On Fri, 20 May 2022 16:27:51 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

GHA testing is not clean.

I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.

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

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

From kvn at openjdk.java.net  Fri Jun 10 04:58:59 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 10 Jun 2022 04:58:59 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
Message-ID: <ouwqCp-CSAB3ivRPWE9Up_AAqtvoLUYFhD-YFSA39dw=.b8fa16d5-2853-49ac-a8bf-877a07ce2f59@github.com>

On Thu, 9 Jun 2022 14:45:36 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
>> 
>> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
>> 
>> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
>> 
>> Example. Dummy method disassembly on AARCH, before vs after:
>> 
>> [Verified Entry Point]                          |  [Verified Entry Point]
>>   78c63b80:   nop                               |    7437e480:   nop
>>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>>   78c63ba0:   .inst   0x00000000 ; undefined    |
>>   78c63ba4:   .inst   0x00000000 ; undefined    |
>>   78c63ba8:   .inst   0x00000000 ; undefined    |
>>   78c63bac:   .inst   0x00000000 ; undefined    |
>>   78c63bb0:   .inst   0x00000000 ; undefined    |
>>   78c63bb4:   .inst   0x00000000 ; undefined    |
>>   78c63bb8:   .inst   0x00000000 ; undefined    |
>>   78c63bbc:   .inst   0x00000000 ; undefined    |
>> [Stub Code]                                     |  [Stub Code]
>>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
>> [Exception Handler]                             |  [Exception Handler]
>>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
>> [Deopt Handler Code]                            |  [Deopt Handler Code]
>>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined
>
> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo fix

My tier1-4 testing passed.

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

Marked as reviewed by kvn (Reviewer).

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

From bulasevich at openjdk.java.net  Fri Jun 10 07:54:00 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Fri, 10 Jun 2022 07:54:00 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v4]
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <hS7PVC6Rj_GFBeox1TvFrk3bqSZJyicYwxkyI6FTCkQ=.72851545-8652-4575-84db-8f3acb764d0c@github.com>

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

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

  comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8453/files
  - new: https://git.openjdk.org/jdk/pull/8453/files/630f9c9c..664ca670

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8453&range=02-03

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

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

From bulasevich at openjdk.java.net  Fri Jun 10 07:54:01 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Fri, 10 Jun 2022 07:54:01 GMT
Subject: RFR: 8287373: remove unnecessary paddings in generated code [v3]
In-Reply-To: <ouwqCp-CSAB3ivRPWE9Up_AAqtvoLUYFhD-YFSA39dw=.b8fa16d5-2853-49ac-a8bf-877a07ce2f59@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
 <8gDhOQnvXqj2Eejm96ixKm8HsfiqkY5zB6K0MbWkOOg=.5fdd70ad-530b-48ef-bcff-2cf002329bbb@github.com>
 <ouwqCp-CSAB3ivRPWE9Up_AAqtvoLUYFhD-YFSA39dw=.b8fa16d5-2853-49ac-a8bf-877a07ce2f59@github.com>
Message-ID: <AgO5abb5dEZYeFQC8lo4tLfUBmStBqoAfBi3lZRG8fs=.035ae430-5b77-47e3-91ec-eceee9c45afa@github.com>

On Fri, 10 Jun 2022 04:55:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> My tier1-4 testing passed.

Thank you!

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

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

From duke at openjdk.java.net  Fri Jun 10 09:38:09 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 10 Jun 2022 09:38:09 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Update with some nit fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8812/files
  - new: https://git.openjdk.org/jdk/pull/8812/files/130a3a6d..864460f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=07-08

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

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

From duke at openjdk.java.net  Fri Jun 10 09:38:11 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 10 Jun 2022 09:38:11 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
Message-ID: <TdvjN0bUKYenuuWRYEo1B-iOVm6uOrtlTcgVcYS1UmQ=.bda41bf3-f316-49dd-8cc9-ddf6fd824a0e@github.com>

On Thu, 9 Jun 2022 12:28:28 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix printing

I reverted to using name_and_sig for output, updated the PR and fixed the nits.

@navyxliu, I did consider moving to `deopt` but opted against it as there are just as long tags in the rest of the set (for example "defaultmethods" and "methodcomparator").

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

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

From duke at openjdk.java.net  Fri Jun 10 09:38:13 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 10 Jun 2022 09:38:13 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <G-EwHFb0ktFmCvXQC2dOytWCg75ioWN6xnLJb5n86ng=.3c13c013-cdcd-46e7-bde9-5580494303cd@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
 <G-EwHFb0ktFmCvXQC2dOytWCg75ioWN6xnLJb5n86ng=.3c13c013-cdcd-46e7-bde9-5580494303cd@github.com>
Message-ID: <uLhZV39r2xYwO_fuLx2RA3Y3-kMfGmQGplqQ9XOLKPI=.3d388d68-122e-44e4-b5c0-91585b569e8e@github.com>

On Thu, 9 Jun 2022 22:21:11 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix printing
>
> src/hotspot/share/runtime/deoptimization.cpp line 1858:
> 
>> 1856:     ls.print("pc=" INTPTR_FORMAT " relative_pc=" INTPTR_FORMAT,
>> 1857:              pc, fr.pc() - nm->code_begin());
>> 1858:     ls.cr();
> 
> nits:  you can combine this with print_cr(). 
> you can move `is_osr` in if (lt.is_enabled()) block.

Fixed!

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

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

From duke at openjdk.java.net  Fri Jun 10 09:40:38 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 10 Jun 2022 09:40:38 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v8]
In-Reply-To: <XQ_hPnSxUxvIgLffO-lwFpoBfWFeqNVM1YfHxg623ss=.c8030b23-3762-41b7-aab9-47db5332fd72@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <L4wZ4wa4W_tvoQBUTRjscd8xogc0fCQqiDdNy1pqvJY=.d7c52559-46c9-42d8-8840-abb7c543b156@github.com>
 <XQ_hPnSxUxvIgLffO-lwFpoBfWFeqNVM1YfHxg623ss=.c8030b23-3762-41b7-aab9-47db5332fd72@github.com>
Message-ID: <3R_i-n80wvzfQz7tdgaJT9L-sTTzE6bRu-0PJaRZK7o=.9a1fc1fe-67fa-4c79-ad7b-0785ccadef06@github.com>

On Thu, 9 Jun 2022 18:04:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix printing
>
> Please, also update the output example in PR's description. It is misleading now.

@vnkozlov, I'm running it on Mach5 Tier1 as I'm writing this comment. Will edit the original PR when it passes.

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

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

From mdoerr at openjdk.java.net  Fri Jun 10 10:38:05 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 10 Jun 2022 10:38:05 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack
Message-ID: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>

Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.

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

Commit messages:
 - 8288105: [PPC64] Problems with -XX:+VerifyStack

Changes: https://git.openjdk.org/jdk19/pull/3/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288105
  Stats: 57 lines in 4 files changed: 10 ins; 33 del; 14 mod
  Patch: https://git.openjdk.org/jdk19/pull/3.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/3/head:pull/3

PR: https://git.openjdk.org/jdk19/pull/3

From aph at openjdk.java.net  Fri Jun 10 10:40:24 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 10 Jun 2022 10:40:24 GMT
Subject: RFR: 8288181: AArch64: clean up out-of-date comments
Message-ID: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>

Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

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

Commit messages:
 - More
 - More
 - 8288181: AArch64: clean up out-of-date comments

Changes: https://git.openjdk.org/jdk/pull/9124/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288181
  Stats: 18 lines in 7 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/9124.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9124/head:pull/9124

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

From mdoerr at openjdk.java.net  Fri Jun 10 10:53:14 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 10 Jun 2022 10:53:14 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

LGTM and sounds feasible.

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

Marked as reviewed by mdoerr (Reviewer).

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

From shade at openjdk.java.net  Fri Jun 10 11:10:00 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 11:10:00 GMT
Subject: RFR: 8288181: AArch64: clean up out-of-date comments
In-Reply-To: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
References: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
Message-ID: <cVvevlcgDd8LhedcO9gi45z6g5FCJm2AfBjZytyq1UI=.78945395-1c87-496b-b60d-36423e0471bc@github.com>

On Fri, 10 Jun 2022 10:30:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From mbaesken at openjdk.java.net  Fri Jun 10 11:30:06 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Jun 2022 11:30:06 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <hhcl2DS9otR1Jql7mhvTBsiP96NUBscYl-i5zXiVIzc=.e1dee9ab-6eff-45b6-b769-8d05bc10871a@github.com>
Message-ID: <1ekFL0P-_g0l_A4cqFl61JU66x4SyCp97VFeqtkX0gw=.0b43bf9e-0dc1-41b2-bb1f-89e8dcd7d393@github.com>

On Fri, 10 Jun 2022 10:49:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM and sounds feasible.

Hi Martin, thanks for the review.

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

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

From duke at openjdk.java.net  Fri Jun 10 11:39:08 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Fri, 10 Jun 2022 11:39:08 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
Message-ID: <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>

On Fri, 10 Jun 2022 01:33:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> GHA testing is not clean.
> 
> I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.

Thank you, Vladimir.

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

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

From thomas.stuefe at gmail.com  Fri Jun 10 12:02:35 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 10 Jun 2022 14:02:35 +0200
Subject: Why no hs_err on SIGABRT?
In-Reply-To: <CAG0Tb0hZ2HiL07K29P3_7CKGc9sfA2h3=bb_E9dwzja=QWq9VA@mail.gmail.com>
References: <CAG0Tb0hZ2HiL07K29P3_7CKGc9sfA2h3=bb_E9dwzja=QWq9VA@mail.gmail.com>
Message-ID: <CAA-vtUxVk4k8-yRCfWB1uo8=RQE55wo6xbxoQPwxMfYiQ6pcTg@mail.gmail.com>

Hi Maxim,

it would be technically a bit fiddly, since the hotspot uses abort(3) at
the end of the error reporting to generate a core; you'd have to prevent
circularities, e.g. by carefully switching off the abort handler before
calling abort.

Then, I believe it would break downward compatibility, since if the VM
starts to use SIGABORT that could conflict with existing applications that
have abort handler registered, requiring them to start using signal
chaining.

It also could break compatibility in a different way, prolonging the time
it takes for the VM to react on a SIGABORT, since error reporting takes
time (we have a complex time out mechanism in the error reporter for that
reason). Applications that abort VM processes and expect those to go
quickly may need to switch to a different signal. There is also the
understanding that SIGABORT kills the process immediately with a core; that
core file would get delayed and could therefore be less useful.

Those are from the top of my head, there may be more issues. Certainly
solvable, but I am not sure the benefit would be that great. In those rare
instances where I had the glibc abort on me, the call stack made it
immediately clear what the problem was. As of
https://bugs.openjdk.org/browse/JDK-8275320, NMT does sanity checks on
malloc/free, enabling us to have those checks in release builds (just
switch on NMT). That leaves allocations from outside hotspot, but there,
the hs-err file would be less useful anyway.

Cheers, Thomas

On Thu, Jun 9, 2022 at 10:39 AM Maxim Kartashev <
maxim.kartashev at jetbrains.com> wrote:

> The very useful hs_err file gets generated in many abnormal situations, but
> program termination by abort() (which generates SIGABRT) isn't one of them.
> I was wondering if this is deliberate and, if so, why?
>
> The use case I have in mind is the utilization of the built-in GNU libc
> heap checks. If, for example, there's a double-free, a chance exists for
> those checks to fire and terminate the program with abort(). In absence of
> core dump, hs_err would provide at least some guidance as to the location
> of the problematic code and, unlike the core file, it will have the java
> stack readily available. It is also quite common for the developers to
> receive hs_err files, but not core files, which are a lot larger, may have
> sensitive information in them, and are often not generated by default.
>

From aph at openjdk.java.net  Fri Jun 10 13:31:03 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 10 Jun 2022 13:31:03 GMT
Subject: Integrated: 8288181: AArch64: clean up out-of-date comments
In-Reply-To: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
References: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
Message-ID: <7a-a1ffFIyd6xUWsrLYIV7PeFlonL6ZYg_X38ElK6lY=.71f5242b-2d84-4af7-bf0d-bc93209fd1f2@github.com>

On Fri, 10 Jun 2022 10:30:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

This pull request has now been integrated.

Changeset: bdd64d6f
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdd64d6f7d5cbb470fc951174145602647d1c283
Stats:     18 lines in 7 files changed: 0 ins; 5 del; 13 mod

8288181: AArch64: clean up out-of-date comments

Reviewed-by: shade

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

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

From mdoerr at openjdk.java.net  Fri Jun 10 14:23:03 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 10 Jun 2022 14:23:03 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v2]
In-Reply-To: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
Message-ID: <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>

> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.

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

  frame::sender_for_compiled_frame: Put sender_sp and _pc into local variables as needed for the Loom port.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/3/files
  - new: https://git.openjdk.org/jdk19/pull/3/files/9626e55a..54b8c52e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=00-01

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

PR: https://git.openjdk.org/jdk19/pull/3

From maxim.kartashev at jetbrains.com  Fri Jun 10 14:42:32 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Fri, 10 Jun 2022 17:42:32 +0300
Subject: Why no hs_err on SIGABRT?
In-Reply-To: <CAA-vtUxVk4k8-yRCfWB1uo8=RQE55wo6xbxoQPwxMfYiQ6pcTg@mail.gmail.com>
References: <CAG0Tb0hZ2HiL07K29P3_7CKGc9sfA2h3=bb_E9dwzja=QWq9VA@mail.gmail.com>
 <CAA-vtUxVk4k8-yRCfWB1uo8=RQE55wo6xbxoQPwxMfYiQ6pcTg@mail.gmail.com>
Message-ID: <CAG0Tb0jJRPxZD4WF42bpdcNP2MZm5RLi_6G2bnAZ1XfJFe0TXA@mail.gmail.com>

Thomas,

thanks you so much for the info! That was quite helpful.

On Fri, Jun 10, 2022 at 3:02 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Maxim,
>
> it would be technically a bit fiddly, since the hotspot uses abort(3) at
> the end of the error reporting to generate a core; you'd have to prevent
> circularities, e.g. by carefully switching off the abort handler before
> calling abort.
>
> Then, I believe it would break downward compatibility, since if the VM
> starts to use SIGABORT that could conflict with existing applications that
> have abort handler registered, requiring them to start using signal
> chaining.
>
> It also could break compatibility in a different way, prolonging the time
> it takes for the VM to react on a SIGABORT, since error reporting takes
> time (we have a complex time out mechanism in the error reporter for that
> reason). Applications that abort VM processes and expect those to go
> quickly may need to switch to a different signal. There is also the
> understanding that SIGABORT kills the process immediately with a core; that
> core file would get delayed and could therefore be less useful.
>
> Those are from the top of my head, there may be more issues. Certainly
> solvable, but I am not sure the benefit would be that great. In those rare
> instances where I had the glibc abort on me, the call stack made it
> immediately clear what the problem was. As of
> https://bugs.openjdk.org/browse/JDK-8275320, NMT does sanity checks on
> malloc/free, enabling us to have those checks in release builds (just
> switch on NMT). That leaves allocations from outside hotspot, but there,
> the hs-err file would be less useful anyway.
>
> Cheers, Thomas
>
> On Thu, Jun 9, 2022 at 10:39 AM Maxim Kartashev <
> maxim.kartashev at jetbrains.com> wrote:
>
>> The very useful hs_err file gets generated in many abnormal situations,
>> but
>> program termination by abort() (which generates SIGABRT) isn't one of
>> them.
>> I was wondering if this is deliberate and, if so, why?
>>
>> The use case I have in mind is the utilization of the built-in GNU libc
>> heap checks. If, for example, there's a double-free, a chance exists for
>> those checks to fire and terminate the program with abort(). In absence of
>> core dump, hs_err would provide at least some guidance as to the location
>> of the problematic code and, unlike the core file, it will have the java
>> stack readily available. It is also quite common for the developers to
>> receive hs_err files, but not core files, which are a lot larger, may have
>> sensitive information in them, and are often not generated by default.
>>
>

From kvn at openjdk.java.net  Fri Jun 10 15:55:02 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 10 Jun 2022 15:55:02 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v7]
In-Reply-To: <Yp9eBam_-SvlFpl13RbsWJcOc6vn5f-nSwn3HSb4-K4=.5c102ca7-c6a1-4dbc-9a15-c3b7b64885fa@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <7-2t69yODmdX6wUiOQHq7LzAEKNCCG5k7Rq6NcGMkfY=.4883470c-c460-45f3-b456-a0a38eedeef7@github.com>
 <hkFzxIc_9NZNNl0wG9WKmWKQKue8Y0ty5UfTA1awe-w=.0dd5a90f-8820-45d0-b99f-94e7b1bdc1a6@github.com>
 <Yp9eBam_-SvlFpl13RbsWJcOc6vn5f-nSwn3HSb4-K4=.5c102ca7-c6a1-4dbc-9a15-c3b7b64885fa@github.com>
Message-ID: <UaXF6QLkjNqALqtTt8baawe0B13y-Eg2GqjeWWxdwT4=.cdcb0fa1-e407-4dc4-9069-dcb069b64dae@github.com>

On Thu, 9 Jun 2022 22:11:14 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Current log line:
>> 
>> `[1.334s][debug][deoptimization] cid=206 level=4 java.util.concurrent.locks.ReentrantLock$Sync::tryRelease trap_bci=26 unstable_if reinterpret pc=0x00007f89dcbf4954 relative_pc=0x0000000000000154`
>
> hi, @jdksjolen , 
> Could you update PR description example?  It looks like you have changed it to a one-liner.  just for a record in case we need to revisit this PR.  
> 
> Do you consider 'deopt' instead of 'deoptimization'? I feel deoptimization is too long as a tag.  Neither of them is a word anyway. :)

> @navyxliu, I did consider moving to `deopt` but opted against it as there are just as long tags in the rest of the set (for example "defaultmethods" and "methodcomparator").

Technically speaking it should be `uncommon_trap_deopt` because it does not cover other case of deoptimization when compiled method deoptimized due to a class change (new related class loading, unloaded, redefined) or re-compilation (from C1 to C2). That path [fetch_unroll_info()](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L163) is not covered by this change (may be another RFE).

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

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

From xliu at openjdk.java.net  Fri Jun 10 16:31:03 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 10 Jun 2022 16:31:03 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
Message-ID: <drOvmBJ-7zXpY13N_nRfkS9RXsf1kn3vsOsj1U8CcnQ=.39a3047c-0df3-4a92-9c63-035cc05d667c@github.com>

On Fri, 10 Jun 2022 09:38:09 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with some nit fixes

LGTM. I am not a reviewer. we need other reviewers to approve it.

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

Marked as reviewed by xliu (Committer).

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

From shade at openjdk.java.net  Fri Jun 10 17:11:02 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 17:11:02 GMT
Subject: Integrated: 8288101: False build warning-as-error with GCC 9 after
 JDK-8214976
In-Reply-To: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
References: <lnoQ-RDKFJRnsGt4ln4aTQIuLrmWIvXifYB0-27cTak=.151d3bcf-bc71-43b0-97b3-e421c8c9f23d@github.com>
Message-ID: <RPEYPycXyNjbOE9brUCcibY0x0EdTT5-fLtO24bl2hg=.47ce37f2-124c-40b9-aed4-d1bbc2bacefd@github.com>

On Thu, 9 Jun 2022 16:35:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> gcc version 9.4.0 (also 9.3.1) produces build warning after [JDK-8214976](https://bugs.openjdk.org/browse/JDK-8214976):
> 
> 
> os_posix.cpp:786:34: error: call to 'exit' declared with attribute warning: use os::exit [-Werror=attribute-warning]
>   786 | ALLOW_C_FUNCTION(::exit, ::exit(num);)
>       | ~~~~~~^~~~~
> 
> 
> Apparently, GCC 9 has a bug with nesting pragmas. The [Godbolt experiments](https://godbolt.org/z/vonsqEnK6) show this only affects GCC 9, and there are no easy way to restructure the macros to dodge this, so the way out to bump the requirement for new macros to GCC >= 10.
> 
> Additional testing:
>  - [x] Linux x86_64 build with GCC 9.4.0 (now passes without warnings)
>  - [x] Linux x86_64 build with GCC 10.2.1 (still passes)

This pull request has now been integrated.

Changeset: d9c1364d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/d9c1364ddecde7e56e165b86e55dc23bda4ff921
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8288101: False build warning-as-error with GCC 9 after JDK-8214976

Reviewed-by: mdoerr, zgu, kbarrett

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

PR: https://git.openjdk.org/jdk19/pull/1

From clanger at openjdk.java.net  Fri Jun 10 20:16:05 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 10 Jun 2022 20:16:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <nvWG4eKOXZIiB9FBNDHzbqmR9jVghlYQAGgDprq1Yl8=.2318a5e3-a50d-4719-b43c-53f0ff1a0138@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

Looks good to me.

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

Marked as reviewed by clanger (Reviewer).

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

From prr at openjdk.java.net  Fri Jun 10 21:08:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 10 Jun 2022 21:08:03 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:

> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
> 37: #else
> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))

If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
#define ROUND_TO_INT(num) ((int) round(num))

.. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.

Same logic applies to the other files.


(*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

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

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

From david.holmes at oracle.com  Sat Jun 11 13:16:26 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 11 Jun 2022 23:16:26 +1000
Subject: Why no hs_err on SIGABRT?
In-Reply-To: <CAA-vtUxVk4k8-yRCfWB1uo8=RQE55wo6xbxoQPwxMfYiQ6pcTg@mail.gmail.com>
References: <CAG0Tb0hZ2HiL07K29P3_7CKGc9sfA2h3=bb_E9dwzja=QWq9VA@mail.gmail.com>
 <CAA-vtUxVk4k8-yRCfWB1uo8=RQE55wo6xbxoQPwxMfYiQ6pcTg@mail.gmail.com>
Message-ID: <ae3d5a09-1fe1-8ff6-f363-3231f8a646c1@oracle.com>

+1 to what Thomas said. I too have not had an issue with tracking down 
glibc aborts.

David

On 10/06/2022 10:02 pm, Thomas St?fe wrote:
> Hi Maxim,
> 
> it would be technically a bit fiddly, since the hotspot uses abort(3) at
> the end of the error reporting to generate a core; you'd have to prevent
> circularities, e.g. by carefully switching off the abort handler before
> calling abort.
> 
> Then, I believe it would break downward compatibility, since if the VM
> starts to use SIGABORT that could conflict with existing applications that
> have abort handler registered, requiring them to start using signal
> chaining.
> 
> It also could break compatibility in a different way, prolonging the time
> it takes for the VM to react on a SIGABORT, since error reporting takes
> time (we have a complex time out mechanism in the error reporter for that
> reason). Applications that abort VM processes and expect those to go
> quickly may need to switch to a different signal. There is also the
> understanding that SIGABORT kills the process immediately with a core; that
> core file would get delayed and could therefore be less useful.
> 
> Those are from the top of my head, there may be more issues. Certainly
> solvable, but I am not sure the benefit would be that great. In those rare
> instances where I had the glibc abort on me, the call stack made it
> immediately clear what the problem was. As of
> https://bugs.openjdk.org/browse/JDK-8275320, NMT does sanity checks on
> malloc/free, enabling us to have those checks in release builds (just
> switch on NMT). That leaves allocations from outside hotspot, but there,
> the hs-err file would be less useful anyway.
> 
> Cheers, Thomas
> 
> On Thu, Jun 9, 2022 at 10:39 AM Maxim Kartashev <
> maxim.kartashev at jetbrains.com> wrote:
> 
>> The very useful hs_err file gets generated in many abnormal situations, but
>> program termination by abort() (which generates SIGABRT) isn't one of them.
>> I was wondering if this is deliberate and, if so, why?
>>
>> The use case I have in mind is the utilization of the built-in GNU libc
>> heap checks. If, for example, there's a double-free, a chance exists for
>> those checks to fire and terminate the program with abort(). In absence of
>> core dump, hs_err would provide at least some guidance as to the location
>> of the problematic code and, unlike the core file, it will have the java
>> stack readily available. It is also quite common for the developers to
>> receive hs_err files, but not core files, which are a lot larger, may have
>> sensitive information in them, and are often not generated by default.
>>

From jiefu at openjdk.java.net  Sat Jun 11 15:14:38 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 11 Jun 2022 15:14:38 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due to
 UseHeavyMonitors is read-only
Message-ID: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>

Hi all,

Zero-release build is broken after JDK-8279047.
After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.

But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.

  // If lock diagnostics is needed, always call to runtime
  if (DiagnoseSyncOnValueBasedClasses != 0) {
    FLAG_SET_DEFAULT(UseHeavyMonitors, true);
  }


I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8288282: Zero-release build is broken after JDK-8279047 due to UseHeavyMonitors is read-only

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

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

From dholmes at openjdk.java.net  Sun Jun 12 04:23:00 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 12 Jun 2022 04:23:00 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only
In-Reply-To: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
Message-ID: <Krq6XK_hdQmqc6wTpQZy6oSMTGoV4KHuOB1nPuOXwYo=.340b0d0a-5f9c-4862-9a60-dd88dc0c7317@github.com>

On Sat, 11 Jun 2022 15:08:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Zero-release build is broken after JDK-8279047.
> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
> 
> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
> 
>   // If lock diagnostics is needed, always call to runtime
>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>   }
> 
> 
> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
> 
> Thanks.
> Best regards,
> Jie

@DamonFool , sorry I missed this when expiring UseHeavyMonitors in product mode. The Zero code should have been fixed long before now. But why not make keep the diagnostics available in the debug VM?

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

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

From jiefu at openjdk.java.net  Sun Jun 12 04:42:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 12 Jun 2022 04:42:49 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
Message-ID: <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>

> Hi all,
> 
> Zero-release build is broken after JDK-8279047.
> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
> 
> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
> 
>   // If lock diagnostics is needed, always call to runtime
>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>   }
> 
> 
> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
> 
> Thanks.
> Best regards,
> Jie

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

  Only disable lock diagnostics for zero product vms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9138/files
  - new: https://git.openjdk.org/jdk/pull/9138/files/c9467b35..710e8ae0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=00-01

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

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

From jiefu at openjdk.java.net  Sun Jun 12 04:42:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 12 Jun 2022 04:42:49 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only
In-Reply-To: <Krq6XK_hdQmqc6wTpQZy6oSMTGoV4KHuOB1nPuOXwYo=.340b0d0a-5f9c-4862-9a60-dd88dc0c7317@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <Krq6XK_hdQmqc6wTpQZy6oSMTGoV4KHuOB1nPuOXwYo=.340b0d0a-5f9c-4862-9a60-dd88dc0c7317@github.com>
Message-ID: <pKrs-kLkbM5cABWGagSx_JTa20d5-efYJ6wes-2IYzs=.a1fb8a5c-ad1b-4cc3-8f05-4e932ae95784@github.com>

On Sun, 12 Jun 2022 04:19:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But why not make keep the diagnostics available in the debug VM?

Updated.
What do you think of this version?
Thanks.

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 07:24:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

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

  use round directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/ee8dc996..e97c8329

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=00-01

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 07:24:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 07:24:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <BWDc3GhMpw9OZ71u7HtHOzza-oh0l2oiw0Zp74gDbu0=.ddccdd37-1179-4aac-b2ed-0927138c6f6a@github.com>
Message-ID: <dNLh7YlIe945J7TSYatk82tCc3HzmB5YF0ogLmt2dVg=.fad405f8-0895-4e22-a7b8-2b09e1afea2a@github.com>

On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:
> 
>> 36: #  define ROUND_TO_INT(num)    ((int) round(num))
>> 37: #else
>> 38: #  define ROUND_TO_INT(num)    ((int) floor((num) + 0.5))
> 
> If you look at when and why this was introduced (*), the "else" was not to support some other compiler - it was to support the older MS compiler. So if you don't want that, then the whole thing reduces to
> #define ROUND_TO_INT(num) ((int) round(num))
> 
> .. you could even go further and eliminate the macro altogether if it makes sense - you'd have to look at the usages.
> 
> Same logic applies to the other files.
> 
> 
> (*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

Hi Phil, I simplified the code more and now use round directly.

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

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

From rehn at openjdk.java.net  Mon Jun 13 07:49:08 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 13 Jun 2022 07:49:08 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v6]
In-Reply-To: <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
Message-ID: <OiUR-GxZJuELeVCJQ5c9RCW2A2W-riXa9Lb1Iplt-FE=.a8b94e59-2157-428f-a8ab-4ae159a5f9c7@github.com>

On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move assert up and remove other assert, remove unused var

The only way to become an active handshaker is to handshake another thread (target), when that happens we verify that target is ThreadsList safe.
Thus active handshaker is guaranteed that the target is already verified on a ThreadsList.
As long as we are the active handshake the target is blocked, i.e. target is safepoint safe.

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

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

From dholmes at openjdk.java.net  Mon Jun 13 07:55:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Jun 2022 07:55:04 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
Message-ID: <uTHvx5sq3N8SuOKmEqLA79-bsaeb15MCApAwWp59lP4=.43f529a3-97af-4f00-ac97-793a2945589c@github.com>

On Sun, 12 Jun 2022 04:42:49 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Zero-release build is broken after JDK-8279047.
>> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
>> 
>> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
>> 
>>   // If lock diagnostics is needed, always call to runtime
>>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>>   }
>> 
>> 
>> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
>> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only disable lock diagnostics for zero product vms

Looks good!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

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

From shade at openjdk.java.net  Mon Jun 13 08:14:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Jun 2022 08:14:47 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
Message-ID: <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>

On Sun, 12 Jun 2022 04:42:49 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Zero-release build is broken after JDK-8279047.
>> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
>> 
>> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
>> 
>>   // If lock diagnostics is needed, always call to runtime
>>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>>   }
>> 
>> 
>> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
>> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only disable lock diagnostics for zero product vms

Unfortunately, that would break:


CONF=linux-x86_64-zero-release make exploded-test TEST=runtime/Monitor/SyncOnValueBasedClassTest.java

java.lang.RuntimeException: 'fatal error: Synchronizing on object' missing from stdout/stderr 


I think the patch should just be:


diff --git a/src/hotspot/cpu/zero/vm_version_zero.cpp b/src/hotspot/cpu/zero/vm_version_zero.cpp
index 5c2a0a3d5d2..df6c7f0eba2 100644
--- a/src/hotspot/cpu/zero/vm_version_zero.cpp
+++ b/src/hotspot/cpu/zero/vm_version_zero.cpp
@@ -47,7 +47,8 @@ void VM_Version::initialize() {
 
   // If lock diagnostics is needed, always call to runtime
   if (DiagnoseSyncOnValueBasedClasses != 0) {
-    FLAG_SET_DEFAULT(UseHeavyMonitors, true);
+    warning("Lock diagnostics is not available on this CPU");
+    FLAG_SET_DEFAULT(DiagnoseSyncOnValueBasedClasses, 0);
   }
 
   if (UseAESIntrinsics) {
diff --git a/test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java b/test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java
index 394a92c0398..1793ba2e0d7 100644
--- a/test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java
+++ b/test/hotspot/jtreg/runtime/Monitor/SyncOnValueBasedClassTest.java
@@ -31,6 +31,7 @@ import java.util.stream.*;
  * @bug 8242263
  * @summary Exercise DiagnoseSyncOnValueBasedClasses diagnostic flag
  * @requires vm.flagless
+ * @requires vm.flavor != "zero"
  * @library /test/lib
  * @run driver/timeout=180000 SyncOnValueBasedClassTest
  */

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

Changes requested by shade (Reviewer).

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

From jiefu at openjdk.java.net  Mon Jun 13 09:09:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 09:09:44 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v3]
In-Reply-To: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
Message-ID: <Xd4bc12VGx88KaqYO01Jmsep5Fbr9SNwqFL0aOS34sE=.5c55b744-5d7d-4576-985d-d738e4f87161@github.com>

> Hi all,
> 
> Zero-release build is broken after JDK-8279047.
> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
> 
> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
> 
>   // If lock diagnostics is needed, always call to runtime
>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>   }
> 
> 
> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
> 
> Thanks.
> Best regards,
> Jie

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

  runtime/Monitor/SyncOnValueBasedClassTest.java shouldn't run with zero-release

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9138/files
  - new: https://git.openjdk.org/jdk/pull/9138/files/710e8ae0..b20267e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=01-02

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

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

From jiefu at openjdk.java.net  Mon Jun 13 09:14:09 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 09:14:09 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
Message-ID: <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>

On Mon, 13 Jun 2022 08:11:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Unfortunately, that would break:
> 
> ```
> CONF=linux-x86_64-zero-release make exploded-test TEST=runtime/Monitor/SyncOnValueBasedClassTest.java
> 
> java.lang.RuntimeException: 'fatal error: Synchronizing on object' missing from stdout/stderr 
> ```

Good catch.
So let's disable the test for zero-release VMs.

I think it's fine to keep the diagnostics for zero debug VM in case someone might use it while debugging.
Thanks.

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

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

From shade at openjdk.java.net  Mon Jun 13 09:22:58 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Jun 2022 09:22:58 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
Message-ID: <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>

On Mon, 13 Jun 2022 09:10:33 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I think it's fine to keep the diagnostics for zero debug VM in case someone might use it while debugging. Thanks.

Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble. Disable `DiagnoseSyncOnValueBasedClasses` wholesale for Zero and disable the test, like my patch did.

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

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

From jiefu at openjdk.java.net  Mon Jun 13 09:42:10 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 09:42:10 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
 <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
Message-ID: <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>

On Mon, 13 Jun 2022 09:19:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble.

So what's the trouble would be?

There are many VM flags which are only available for debug VMs.

./share/runtime/globals.hpp:  develop(bool, LargePagesIndividualAllocationInjectError, false,           \
./share/runtime/globals.hpp:  develop(bool, TracePcPatching, false,                                     \
./share/runtime/globals.hpp:  develop(bool, TraceRelocator, false,                                      \
./share/runtime/globals.hpp:  develop(bool, VerifyStack, false,                                         \
./share/runtime/globals.hpp:  develop(bool, TraceDerivedPointers, false,                                \
./share/runtime/globals.hpp:  develop(bool, TraceCallFixup, false,                                      \
./share/runtime/globals.hpp:  develop(bool, DeoptimizeALot, false,                                      \
./share/runtime/globals.hpp:  develop(bool, DeoptimizeRandom, false,                                    \
./share/runtime/globals.hpp:  develop(bool, DeoptimizeObjectsALot, false,                               \
./share/runtime/globals.hpp:  develop(uint64_t, DeoptimizeObjectsALotInterval, 5,                       \
./share/runtime/globals.hpp:  develop(int, DeoptimizeObjectsALotThreadCountSingle, 1,                   \
./share/runtime/globals.hpp:  develop(int, DeoptimizeObjectsALotThreadCountAll, 1,                      \
./share/runtime/globals.hpp:  develop(bool, VerifyStackAtCalls, false,                                  \
./share/runtime/globals.hpp:  develop(bool, TraceJavaAssertions, false,                                 \
./share/runtime/globals.hpp:  develop(bool, UseMallocOnly, false,                                       \
./share/runtime/globals.hpp:  develop(bool, ZapResourceArea, trueInDebug,                               \
./share/runtime/globals.hpp:  develop(bool, ZapUnusedHeapArea, trueInDebug,                             \
./share/runtime/globals.hpp:  develop(bool, CheckZapUnusedHeapArea, false,                              \
./share/runtime/globals.hpp:  develop(bool, ZapFillerObjects, trueInDebug,                              \
./share/runtime/globals.hpp:  develop(uintx, ErrorHandlerTest, 0,                                       \
./share/runtime/globals.hpp:  develop(uintx, TestCrashInErrorHandler, 0,                                \
./share/runtime/globals.hpp:  develop(bool, TestSafeFetchInErrorHandler, false   ,                      \
./share/runtime/globals.hpp:  develop(bool, TestUnresponsiveErrorHandler, false,                        \
./share/runtime/globals.hpp:  develop(bool, Verbose, false,                                             \
./share/runtime/globals.hpp:  develop(bool, PrintMiscellaneous, false,                                  \
./share/runtime/globals.hpp:  develop(bool, WizardMode, false,                                          \
./share/runtime/globals.hpp:  develop(bool, VerifyAdapterSharing, false,                                \
./share/runtime/globals.hpp:  develop(bool, PrintDebugInfo, false,                                      \
./share/runtime/globals.hpp:  develop(bool, PrintRelocations, false,                                    \
./share/runtime/globals.hpp:  develop(bool, PrintDependencies, false,                                   \
./share/runtime/globals.hpp:  develop(bool, PrintExceptionHandlers, false,                              \
./share/runtime/globals.hpp:  develop(bool, StressCompiledExceptionHandlers, false,                     \
./share/runtime/globals.hpp:  develop(bool, InterceptOSException, false,                                \
./share/runtime/globals.hpp:  develop(bool, PrintCodeCache2, false,                                     \
./share/runtime/globals.hpp:  develop(bool, RegisterReferences, true,                                   \
./share/runtime/globals.hpp:  develop(bool, PrintCodeCacheExtension, false,                             \
./share/runtime/globals.hpp:  develop(bool, UsePrivilegedStack, true,                                   \
./share/runtime/globals.hpp:  develop(bool, LoadLineNumberTables, true,                                 \
./share/runtime/globals.hpp:  develop(bool, LoadLocalVariableTables, true,                              \
./share/runtime/globals.hpp:  develop(bool, LoadLocalVariableTypeTables, true,                          \
./share/runtime/globals.hpp:  develop(uintx, PreallocatedOutOfMemoryErrorCount, 4,                      \
./share/runtime/globals.hpp:  develop(bool, StressRewriter, false,                                      \
./share/runtime/globals.hpp:  develop(bool, TraceBytecodes, false,                                      \
./share/runtime/globals.hpp:  develop(bool, TraceICs, false,                                            \
./share/runtime/globals.hpp:  develop(bool, TraceInlineCacheClearing, false,                            \
./share/runtime/globals.hpp:  develop(bool, TraceDependencies, false,                                   \
./share/runtime/globals.hpp:  develop(bool, VerifyDependencies, trueInDebug,                            \
./share/runtime/globals.hpp:  develop(bool, TraceNewOopMapGeneration, false,                            \
./share/runtime/globals.hpp:  develop(bool, TraceNewOopMapGenerationDetailed, false,                    \
./share/runtime/globals.hpp:  develop(bool, TimeOopMap, false,                                          \
./share/runtime/globals.hpp:  develop(bool, TimeOopMap2, false,                                         \
./share/runtime/globals.hpp:  develop(bool, TraceOopMapRewrites, false,                                 \
./share/runtime/globals.hpp:  develop(bool, TraceICBuffer, false,                                       \
./share/runtime/globals.hpp:  develop(bool, TraceCompiledIC, false,                                     \
./share/runtime/globals.hpp:  develop(bool, FLSVerifyDictionary, false,                                 \
./share/runtime/globals.hpp:  develop(bool, TraceFinalizerRegistration, false,                          \
./share/runtime/globals.hpp:  develop(bool, InjectCompilerCreationFailure, false,                       \
./share/runtime/globals.hpp:  develop(bool, GenerateSynchronizationCode, true,                          \
./share/runtime/globals.hpp:  develop(bool, GenerateRangeChecks, true,                                  \
./share/runtime/globals.hpp:  develop(bool, UseCHA, true,                                               \
./share/runtime/globals.hpp:  develop(bool, TraceMethodReplacement, false,                              \
./share/runtime/globals.hpp:  develop(bool, PrintMethodFlushing, false,                                 \
./share/runtime/globals.hpp:  develop(bool, StressCodeBuffers, false,                                   \
./share/runtime/globals.hpp:  develop(bool, UseHeavyMonitors, false,                                    \
./share/runtime/globals.hpp:  develop(bool, VerifyHeavyMonitors, false,                                 \
./share/runtime/globals.hpp:  develop(bool, DebugVtables, false,                                        \
./share/runtime/globals.hpp:  develop(bool, TraceCreateZombies, false,                                  \
./share/runtime/globals.hpp:  develop(bool, TypeProfileCasts,  true,                                    \
./share/runtime/globals.hpp:  develop(bool, TraceLivenessGen, false,                                    \
./share/runtime/globals.hpp:  develop(intx, FastAllocateSizeLimit, 128*K,                               \
./share/runtime/globals.hpp:  develop(bool, CountCompiledCalls, false,                                  \
./share/runtime/globals.hpp:  develop(bool, UseFastSignatureHandlers, true,                             \
./share/runtime/globals.hpp:  develop(bool, CountBytecodes, false,                                      \
./share/runtime/globals.hpp:  develop(bool, PrintBytecodeHistogram, false,                              \
./share/runtime/globals.hpp:  develop(bool, PrintBytecodePairHistogram, false,                          \
./share/runtime/globals.hpp:  develop(bool, VerifyOops, false,                                          \
./share/runtime/globals.hpp:  develop(bool, CheckUnhandledOops, false,                                  \
./share/runtime/globals.hpp:  develop(bool, VerifyJNIFields, trueInDebug,                               \
./share/runtime/globals.hpp:  develop(bool, VerifyFPU, false,                                           \
./share/runtime/globals.hpp:  develop(bool, VerifyThread, false,                                        \
./share/runtime/globals.hpp:  develop(bool, VerifyActivationFrameSize, false,                           \
./share/runtime/globals.hpp:  develop(bool, TraceFrequencyInlining, false,                              \
./share/runtime/globals.hpp:  develop(bool, VerifyDataPointer, trueInDebug,                             \
./share/runtime/globals.hpp:  develop(intx, CounterHalfLifeTime,    30,                                 \
./share/runtime/globals.hpp:  develop(intx, CounterDecayMinIntervalLength,   500,                       \
./share/runtime/globals.hpp:  develop(bool, PrintDeoptimizationDetails, false,                          \
./share/runtime/globals.hpp:  develop(bool, DebugDeoptimization, false,                                 \
./share/runtime/globals.hpp:  develop(intx, MallocCatchPtr, -1,                                         \
./share/runtime/globals.hpp:  develop(intx, StackPrintLimit, 100,                                       \
./share/runtime/globals.hpp:  develop(intx, MaxForceInlineLevel, 100,                                   \
./share/runtime/globals.hpp:  develop(intx, MethodHistogramCutoff, 100,                                 \
./share/runtime/globals.hpp:  develop(intx, DontYieldALotInterval,    10,                               \
./share/runtime/globals.hpp:  develop(intx, BciProfileWidth,      2,                                    \
./share/runtime/globals.hpp:  develop(intx, InlineThrowCount,    50,                                    \
./share/runtime/globals.hpp:  develop(intx, InlineThrowMaxSize,   200,                                  \
./share/runtime/globals.hpp:  develop(size_t, CompressedClassSpaceBaseAddress, 0,                       \
./share/runtime/globals.hpp:  develop(bool, MetaspaceGuardAllocations, false,                           \
./share/runtime/globals.hpp:  develop(intx, BinarySwitchThreshold, 5,                                   \
./share/runtime/globals.hpp:  develop(intx, StopInterpreterAt, 0,                                       \
./share/runtime/globals.hpp:  develop(intx, TraceBytecodesAt, 0,                                        \
./share/runtime/globals.hpp:  develop(intx, NewCodeParameter,      0,                                   \
./share/runtime/globals.hpp:  develop(intx, MinOopMapAllocation,     8,                                 \
./share/runtime/globals.hpp:  develop(bool, LoomDeoptAfterThaw, false,                                  \
./share/runtime/globals.hpp:  develop(bool, LoomVerifyAfterThaw, false,                                 \
./share/runtime/globals.hpp:  develop(bool, VerifyContinuations, false,                                 \
./share/runtime/globals.hpp:  develop(bool, UseContinuationFastPath, true,                              \
./share/runtime/globals.hpp:  develop(int, VerifyMetaspaceInterval, DEBUG_ONLY(500) NOT_DEBUG(0),       \
./share/runtime/globals.hpp:  develop(bool, TraceMemoryWriteback, false,                                \
./share/runtime/globals.hpp:  develop(bool, VerifyCrossModifyFence,                                     \
./share/runtime/globals.hpp:  develop(bool, TraceOptimizedUpcallStubs, false,                              \

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

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

From shade at openjdk.java.net  Mon Jun 13 09:45:51 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Jun 2022 09:45:51 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
 <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
 <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>
Message-ID: <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>

On Mon, 13 Jun 2022 09:38:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble.
> 
> So what's the trouble would be?
> There are many VM flags which are only available for debug VMs.

Those flags are usually having the same value for release and debug VMs. Your current patch changes the flag values depending on VM mode, which exposes potentially different behaviors depending on VM mode. Imagine chasing a bug in `release` VM that does not reproduce in `debug` VM, those are not fun. Let's not do that. It would be all around easier and safer. to just disable to flag in all VM modes.

The block your patch is modifying is added by me in JDK-8273486, I say we just redo it without involving `UseHeavyMonitors` at all, and just disable the test that is affected by it.

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

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

From goetz at openjdk.java.net  Mon Jun 13 10:08:52 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Mon, 13 Jun 2022 10:08:52 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v2]
In-Reply-To: <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
Message-ID: <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>

On Fri, 10 Jun 2022 14:23:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
>> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   frame::sender_for_compiled_frame: Put sender_sp and _pc into local variables as needed for the Loom port.

src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 88:

> 86: 
> 87: inline frame::frame(intptr_t* sp, address pc, intptr_t* unextended_sp, intptr_t* fp, CodeBlob* cb)
> 88:   : _sp(sp), _pc(pc), _cb(nullptr), _oop_map(nullptr),

Oops, cb was never used? Good fix.

src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 89:

> 87: 
> 88: inline frame::frame(intptr_t* sp) : frame(sp, nullptr) {}
> 89: 

After you added default arguments to the other constructor, why not add one for pc, too?

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

PR: https://git.openjdk.org/jdk19/pull/3

From mdoerr at openjdk.java.net  Mon Jun 13 10:12:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:12:07 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <m5D_rDzd-3NEkUD13SO3ZeXoKJFvWPAR7B-HUshyNlw=.e94d9098-4e20-451a-b58d-df86c87b87c7@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

Nice!

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

Marked as reviewed by mdoerr (Reviewer).

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

From mdoerr at openjdk.java.net  Mon Jun 13 10:16:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:16:07 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v2]
In-Reply-To: <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
 <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
Message-ID: <-XL9SiBDD0AvZRvCZauvAa9cT4y18BrqJhgvN2sLyQo=.430f5590-fc1a-482d-b378-3dbfac4fd6ca@github.com>

On Mon, 13 Jun 2022 10:03:23 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   frame::sender_for_compiled_frame: Put sender_sp and _pc into local variables as needed for the Loom port.
>
> src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 89:
> 
>> 87: 
>> 88: inline frame::frame(intptr_t* sp) : frame(sp, nullptr) {}
>> 89: 
> 
> After you added default arguments to the other constructor, why not add one for pc, too?

`explicit frame(intptr_t* sp)` is defined in shared code (frame.hpp). I don't want to add a default argument there.

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

PR: https://git.openjdk.org/jdk19/pull/3

From mdoerr at openjdk.java.net  Mon Jun 13 10:31:18 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:31:18 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v3]
In-Reply-To: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
Message-ID: <-ckt6BLyFE3bl34L2kG9qkjN9gQrxIZMYlSt2Jqy6Hs=.30a4b312-609f-4dd4-8126-c245f57ad34a@github.com>

> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.

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

  Simplify frame(void* sp, void* fp, void* pc).

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/3/files
  - new: https://git.openjdk.org/jdk19/pull/3/files/54b8c52e..63dc3c61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=01-02

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

PR: https://git.openjdk.org/jdk19/pull/3

From mdoerr at openjdk.java.net  Mon Jun 13 10:35:14 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:35:14 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v2]
In-Reply-To: <-XL9SiBDD0AvZRvCZauvAa9cT4y18BrqJhgvN2sLyQo=.430f5590-fc1a-482d-b378-3dbfac4fd6ca@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
 <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
 <-XL9SiBDD0AvZRvCZauvAa9cT4y18BrqJhgvN2sLyQo=.430f5590-fc1a-482d-b378-3dbfac4fd6ca@github.com>
Message-ID: <7t90YdJlWWu39fa-xFoWQqYpQt6Uq2Il40RpIl2XlvM=.6d50c6de-955a-4d56-be46-960362d7fa4a@github.com>

On Mon, 13 Jun 2022 10:12:34 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 89:
>> 
>>> 87: 
>>> 88: inline frame::frame(intptr_t* sp) : frame(sp, nullptr) {}
>>> 89: 
>> 
>> After you added default arguments to the other constructor, why not add one for pc, too?
>
> `explicit frame(intptr_t* sp)` is defined in shared code (frame.hpp). I don't want to add a default argument there.

But your question was good. I noticed that we should also simplify the constructor for "pns". See 3rd commit.

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

PR: https://git.openjdk.org/jdk19/pull/3

From aturbanov at openjdk.java.net  Mon Jun 13 10:36:54 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Jun 2022 10:36:54 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
Message-ID: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use round directly

src/hotspot/share/adlc/main.cpp line 491:

> 489: }
> 490: 
> 491: // VS2005 has its own definition, identical to this one.

Let's adjust comment too. No need to mention VS2005.

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

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

From mdoerr at openjdk.java.net  Mon Jun 13 10:39:13 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 10:39:13 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v3]
In-Reply-To: <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
 <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
Message-ID: <3lwpmBO4hm4LpbBdljXKf1CWkTFYZgZCVaoTIDtZltg=.3830719a-a98e-40a5-b8dc-09fdb928d550@github.com>

On Mon, 13 Jun 2022 10:04:09 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify frame(void* sp, void* fp, void* pc).
>
> src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 88:
> 
>> 86: 
>> 87: inline frame::frame(intptr_t* sp, address pc, intptr_t* unextended_sp, intptr_t* fp, CodeBlob* cb)
>> 88:   : _sp(sp), _pc(pc), _cb(nullptr), _oop_map(nullptr),
> 
> Oops, cb was never used? Good fix.

Yeah, it's currently not used, but should better get fixed.

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

PR: https://git.openjdk.org/jdk19/pull/3

From jiefu at openjdk.java.net  Mon Jun 13 10:45:58 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 10:45:58 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v4]
In-Reply-To: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
Message-ID: <MXVD9DnqlL-5UWL4iHkvHz9ncs35YLRf6FrracYozI0=.d4aed995-fa3e-4aa2-be3a-d603dc651a56@github.com>

> Hi all,
> 
> Zero-release build is broken after JDK-8279047.
> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
> 
> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
> 
>   // If lock diagnostics is needed, always call to runtime
>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>   }
> 
> 
> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
> 
> Thanks.
> Best regards,
> Jie

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

  Disable lock diagnostics for all zero versions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9138/files
  - new: https://git.openjdk.org/jdk/pull/9138/files/b20267e5..cfe139fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9138&range=02-03

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

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

From shade at openjdk.java.net  Mon Jun 13 10:45:59 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Jun 2022 10:45:59 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v4]
In-Reply-To: <MXVD9DnqlL-5UWL4iHkvHz9ncs35YLRf6FrracYozI0=.d4aed995-fa3e-4aa2-be3a-d603dc651a56@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <MXVD9DnqlL-5UWL4iHkvHz9ncs35YLRf6FrracYozI0=.d4aed995-fa3e-4aa2-be3a-d603dc651a56@github.com>
Message-ID: <bhXSp0HPfpgSmJf6pRUsuCBGmFxDdMik-sy9ecsgDFg=.77a63b90-c122-4243-971c-170bf3df9456@github.com>

On Mon, 13 Jun 2022 10:41:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Zero-release build is broken after JDK-8279047.
>> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
>> 
>> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
>> 
>>   // If lock diagnostics is needed, always call to runtime
>>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>>   }
>> 
>> 
>> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
>> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable lock diagnostics for all zero versions

Marked as reviewed by shade (Reviewer).

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

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

From jiefu at openjdk.java.net  Mon Jun 13 10:46:00 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 10:46:00 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
 <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
 <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>
 <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>
Message-ID: <06Gfxl5qSKL8BBFRNuHZC9felmiF74SD2l0xU4w9Czw=.8601d2a1-c36c-4ec1-bd84-5b95875ae859@github.com>

On Mon, 13 Jun 2022 09:42:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The block your patch is modifying is added by me in JDK-8273486, I say we just redo it without involving `UseHeavyMonitors` at all, and just disable the test that is affected by it.

Okay.
I didn't notice that you're the original author of the code.
Updated.
Thanks.

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

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

From dholmes at openjdk.java.net  Mon Jun 13 11:29:07 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Jun 2022 11:29:07 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v4]
In-Reply-To: <MXVD9DnqlL-5UWL4iHkvHz9ncs35YLRf6FrracYozI0=.d4aed995-fa3e-4aa2-be3a-d603dc651a56@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <MXVD9DnqlL-5UWL4iHkvHz9ncs35YLRf6FrracYozI0=.d4aed995-fa3e-4aa2-be3a-d603dc651a56@github.com>
Message-ID: <a0qWDO-6PGkc3uBjZ7shTH75DDgZwLwVdSfN6UX3qwk=.d0757c8f-3dd1-43f8-ba6d-cf476fda97fc@github.com>

On Mon, 13 Jun 2022 10:45:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Zero-release build is broken after JDK-8279047.
>> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
>> 
>> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
>> 
>>   // If lock diagnostics is needed, always call to runtime
>>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>>   }
>> 
>> 
>> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
>> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable lock diagnostics for all zero versions

Marked as reviewed by dholmes (Reviewer).

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

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

From dholmes at openjdk.java.net  Mon Jun 13 11:29:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Jun 2022 11:29:08 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
 <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
 <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>
 <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>
Message-ID: <vGW9DqfnKmIZQliwhWlMHWBEeHoDWbxU93JO9JY65gE=.e4c55838-7f0e-4660-9c34-d8e75d824b8f@github.com>

On Mon, 13 Jun 2022 09:42:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble.
>> 
>> So what's the trouble would be?
>> 
>> There are many VM flags which are only available for debug VMs.
>> 
>> ./share/runtime/globals.hpp:  develop(bool, LargePagesIndividualAllocationInjectError, false,           \
>> ./share/runtime/globals.hpp:  develop(bool, TracePcPatching, false,                                     \
>> ./share/runtime/globals.hpp:  develop(bool, TraceRelocator, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyStack, false,                                         \
>> ./share/runtime/globals.hpp:  develop(bool, TraceDerivedPointers, false,                                \
>> ./share/runtime/globals.hpp:  develop(bool, TraceCallFixup, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, DeoptimizeALot, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, DeoptimizeRandom, false,                                    \
>> ./share/runtime/globals.hpp:  develop(bool, DeoptimizeObjectsALot, false,                               \
>> ./share/runtime/globals.hpp:  develop(uint64_t, DeoptimizeObjectsALotInterval, 5,                       \
>> ./share/runtime/globals.hpp:  develop(int, DeoptimizeObjectsALotThreadCountSingle, 1,                   \
>> ./share/runtime/globals.hpp:  develop(int, DeoptimizeObjectsALotThreadCountAll, 1,                      \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyStackAtCalls, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, TraceJavaAssertions, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, UseMallocOnly, false,                                       \
>> ./share/runtime/globals.hpp:  develop(bool, ZapResourceArea, trueInDebug,                               \
>> ./share/runtime/globals.hpp:  develop(bool, ZapUnusedHeapArea, trueInDebug,                             \
>> ./share/runtime/globals.hpp:  develop(bool, CheckZapUnusedHeapArea, false,                              \
>> ./share/runtime/globals.hpp:  develop(bool, ZapFillerObjects, trueInDebug,                              \
>> ./share/runtime/globals.hpp:  develop(uintx, ErrorHandlerTest, 0,                                       \
>> ./share/runtime/globals.hpp:  develop(uintx, TestCrashInErrorHandler, 0,                                \
>> ./share/runtime/globals.hpp:  develop(bool, TestSafeFetchInErrorHandler, false   ,                      \
>> ./share/runtime/globals.hpp:  develop(bool, TestUnresponsiveErrorHandler, false,                        \
>> ./share/runtime/globals.hpp:  develop(bool, Verbose, false,                                             \
>> ./share/runtime/globals.hpp:  develop(bool, PrintMiscellaneous, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, WizardMode, false,                                          \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyAdapterSharing, false,                                \
>> ./share/runtime/globals.hpp:  develop(bool, PrintDebugInfo, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, PrintRelocations, false,                                    \
>> ./share/runtime/globals.hpp:  develop(bool, PrintDependencies, false,                                   \
>> ./share/runtime/globals.hpp:  develop(bool, PrintExceptionHandlers, false,                              \
>> ./share/runtime/globals.hpp:  develop(bool, StressCompiledExceptionHandlers, false,                     \
>> ./share/runtime/globals.hpp:  develop(bool, InterceptOSException, false,                                \
>> ./share/runtime/globals.hpp:  develop(bool, PrintCodeCache2, false,                                     \
>> ./share/runtime/globals.hpp:  develop(bool, RegisterReferences, true,                                   \
>> ./share/runtime/globals.hpp:  develop(bool, PrintCodeCacheExtension, false,                             \
>> ./share/runtime/globals.hpp:  develop(bool, UsePrivilegedStack, true,                                   \
>> ./share/runtime/globals.hpp:  develop(bool, LoadLineNumberTables, true,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, LoadLocalVariableTables, true,                              \
>> ./share/runtime/globals.hpp:  develop(bool, LoadLocalVariableTypeTables, true,                          \
>> ./share/runtime/globals.hpp:  develop(uintx, PreallocatedOutOfMemoryErrorCount, 4,                      \
>> ./share/runtime/globals.hpp:  develop(bool, StressRewriter, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, TraceBytecodes, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, TraceICs, false,                                            \
>> ./share/runtime/globals.hpp:  develop(bool, TraceInlineCacheClearing, false,                            \
>> ./share/runtime/globals.hpp:  develop(bool, TraceDependencies, false,                                   \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyDependencies, trueInDebug,                            \
>> ./share/runtime/globals.hpp:  develop(bool, TraceNewOopMapGeneration, false,                            \
>> ./share/runtime/globals.hpp:  develop(bool, TraceNewOopMapGenerationDetailed, false,                    \
>> ./share/runtime/globals.hpp:  develop(bool, TimeOopMap, false,                                          \
>> ./share/runtime/globals.hpp:  develop(bool, TimeOopMap2, false,                                         \
>> ./share/runtime/globals.hpp:  develop(bool, TraceOopMapRewrites, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, TraceICBuffer, false,                                       \
>> ./share/runtime/globals.hpp:  develop(bool, TraceCompiledIC, false,                                     \
>> ./share/runtime/globals.hpp:  develop(bool, FLSVerifyDictionary, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, TraceFinalizerRegistration, false,                          \
>> ./share/runtime/globals.hpp:  develop(bool, InjectCompilerCreationFailure, false,                       \
>> ./share/runtime/globals.hpp:  develop(bool, GenerateSynchronizationCode, true,                          \
>> ./share/runtime/globals.hpp:  develop(bool, GenerateRangeChecks, true,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, UseCHA, true,                                               \
>> ./share/runtime/globals.hpp:  develop(bool, TraceMethodReplacement, false,                              \
>> ./share/runtime/globals.hpp:  develop(bool, PrintMethodFlushing, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, StressCodeBuffers, false,                                   \
>> ./share/runtime/globals.hpp:  develop(bool, UseHeavyMonitors, false,                                    \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyHeavyMonitors, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, DebugVtables, false,                                        \
>> ./share/runtime/globals.hpp:  develop(bool, TraceCreateZombies, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, TypeProfileCasts,  true,                                    \
>> ./share/runtime/globals.hpp:  develop(bool, TraceLivenessGen, false,                                    \
>> ./share/runtime/globals.hpp:  develop(intx, FastAllocateSizeLimit, 128*K,                               \
>> ./share/runtime/globals.hpp:  develop(bool, CountCompiledCalls, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, UseFastSignatureHandlers, true,                             \
>> ./share/runtime/globals.hpp:  develop(bool, CountBytecodes, false,                                      \
>> ./share/runtime/globals.hpp:  develop(bool, PrintBytecodeHistogram, false,                              \
>> ./share/runtime/globals.hpp:  develop(bool, PrintBytecodePairHistogram, false,                          \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyOops, false,                                          \
>> ./share/runtime/globals.hpp:  develop(bool, CheckUnhandledOops, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyJNIFields, trueInDebug,                               \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyFPU, false,                                           \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyThread, false,                                        \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyActivationFrameSize, false,                           \
>> ./share/runtime/globals.hpp:  develop(bool, TraceFrequencyInlining, false,                              \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyDataPointer, trueInDebug,                             \
>> ./share/runtime/globals.hpp:  develop(intx, CounterHalfLifeTime,    30,                                 \
>> ./share/runtime/globals.hpp:  develop(intx, CounterDecayMinIntervalLength,   500,                       \
>> ./share/runtime/globals.hpp:  develop(bool, PrintDeoptimizationDetails, false,                          \
>> ./share/runtime/globals.hpp:  develop(bool, DebugDeoptimization, false,                                 \
>> ./share/runtime/globals.hpp:  develop(intx, MallocCatchPtr, -1,                                         \
>> ./share/runtime/globals.hpp:  develop(intx, StackPrintLimit, 100,                                       \
>> ./share/runtime/globals.hpp:  develop(intx, MaxForceInlineLevel, 100,                                   \
>> ./share/runtime/globals.hpp:  develop(intx, MethodHistogramCutoff, 100,                                 \
>> ./share/runtime/globals.hpp:  develop(intx, DontYieldALotInterval,    10,                               \
>> ./share/runtime/globals.hpp:  develop(intx, BciProfileWidth,      2,                                    \
>> ./share/runtime/globals.hpp:  develop(intx, InlineThrowCount,    50,                                    \
>> ./share/runtime/globals.hpp:  develop(intx, InlineThrowMaxSize,   200,                                  \
>> ./share/runtime/globals.hpp:  develop(size_t, CompressedClassSpaceBaseAddress, 0,                       \
>> ./share/runtime/globals.hpp:  develop(bool, MetaspaceGuardAllocations, false,                           \
>> ./share/runtime/globals.hpp:  develop(intx, BinarySwitchThreshold, 5,                                   \
>> ./share/runtime/globals.hpp:  develop(intx, StopInterpreterAt, 0,                                       \
>> ./share/runtime/globals.hpp:  develop(intx, TraceBytecodesAt, 0,                                        \
>> ./share/runtime/globals.hpp:  develop(intx, NewCodeParameter,      0,                                   \
>> ./share/runtime/globals.hpp:  develop(intx, MinOopMapAllocation,     8,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, LoomDeoptAfterThaw, false,                                  \
>> ./share/runtime/globals.hpp:  develop(bool, LoomVerifyAfterThaw, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyContinuations, false,                                 \
>> ./share/runtime/globals.hpp:  develop(bool, UseContinuationFastPath, true,                              \
>> ./share/runtime/globals.hpp:  develop(int, VerifyMetaspaceInterval, DEBUG_ONLY(500) NOT_DEBUG(0),       \
>> ./share/runtime/globals.hpp:  develop(bool, TraceMemoryWriteback, false,                                \
>> ./share/runtime/globals.hpp:  develop(bool, VerifyCrossModifyFence,                                     \
>> ./share/runtime/globals.hpp:  develop(bool, TraceOptimizedUpcallStubs, false,                              \
>
>> > Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble.
>> 
>> So what's the trouble would be?
>> There are many VM flags which are only available for debug VMs.
> 
> Those flags are usually having the same value for release and debug VMs. Your current patch changes the flag values depending on VM mode, which exposes potentially different behaviors depending on VM mode. Imagine chasing a bug in `release` VM that does not reproduce in `debug` VM, those are not fun. Let's not do that. It would be all around easier and safer. to just disable to flag in all VM modes.
> 
> The block your patch is modifying is added by me in JDK-8273486, I say we just redo it without involving `UseHeavyMonitors` at all, and just disable the test that is affected by it.

It made more sense to me to keep what was the existing debug behaviour, but I don't have any interest in Zero at all, so whatever you want to do @shipilev is fine by me.

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

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

From goetz at openjdk.java.net  Mon Jun 13 11:31:02 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Mon, 13 Jun 2022 11:31:02 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v3]
In-Reply-To: <-ckt6BLyFE3bl34L2kG9qkjN9gQrxIZMYlSt2Jqy6Hs=.30a4b312-609f-4dd4-8126-c245f57ad34a@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <-ckt6BLyFE3bl34L2kG9qkjN9gQrxIZMYlSt2Jqy6Hs=.30a4b312-609f-4dd4-8126-c245f57ad34a@github.com>
Message-ID: <ZfXhxgSFvgybHSdrL_yzsH96PBiOjKHsezGIsl62uBw=.9ce75b8d-97dd-4f12-8f4c-759fe91c60b8@github.com>

On Mon, 13 Jun 2022 10:31:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
>> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify frame(void* sp, void* fp, void* pc).

Marked as reviewed by goetz (Reviewer).

src/hotspot/cpu/ppc/frame_ppc.cpp line 397:

> 395: #ifndef PRODUCT
> 396: // This is a generic constructor which is only used by pns() in debug.cpp.
> 397: frame::frame(void* sp, void* fp, void* pc) : frame((intptr_t*)sp, (address)pc) {}

You might add a comment that fp is dropped intensionally.  Only a nice to have ...

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

PR: https://git.openjdk.org/jdk19/pull/3

From goetz at openjdk.java.net  Mon Jun 13 11:31:03 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Mon, 13 Jun 2022 11:31:03 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v2]
In-Reply-To: <7t90YdJlWWu39fa-xFoWQqYpQt6Uq2Il40RpIl2XlvM=.6d50c6de-955a-4d56-be46-960362d7fa4a@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <1-1HlzjTZy__ZAnPTiXdJcQyVpubUI0mD7hgzi_y79M=.f82d818b-5a19-45df-94ea-f319d42f721b@github.com>
 <QpTDSYuFxTkbX75Be5FnnLWRIizTss3pZxsvIMc8-io=.a2202cdd-822c-447c-b3c1-a0123c02b529@github.com>
 <-XL9SiBDD0AvZRvCZauvAa9cT4y18BrqJhgvN2sLyQo=.430f5590-fc1a-482d-b378-3dbfac4fd6ca@github.com>
 <7t90YdJlWWu39fa-xFoWQqYpQt6Uq2Il40RpIl2XlvM=.6d50c6de-955a-4d56-be46-960362d7fa4a@github.com>
Message-ID: <J91-J--vgfFnL_j-TJTxy8-4KVr8yp7VbfD2i4S8nM4=.f85e5ae1-da44-4d33-afe5-6d67b13830b3@github.com>

On Mon, 13 Jun 2022 10:31:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> `explicit frame(intptr_t* sp)` is defined in shared code (frame.hpp). I don't want to add a default argument there.
>
> But your question was good. I noticed that we should also simplify the constructor for "pns". See 3rd commit.

OK, that makes sense. Thanks

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

PR: https://git.openjdk.org/jdk19/pull/3

From duke at openjdk.java.net  Mon Jun 13 11:37:56 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Mon, 13 Jun 2022 11:37:56 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
Message-ID: <XJaweiudZuAVqji2VD4bmjmIaxzr9dFTVP_Gr3D06AQ=.bc6f8baf-ca3a-4bd9-b8ea-0078784a5a58@github.com>

On Fri, 10 Jun 2022 09:38:09 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with some nit fixes

Both Jorn and Vladimir are reviewers for JDK so I believe that we're fulfilling the requirements.

@JornVernee , @vnkozlov , could I have a re-approve on this latest commit?

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

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

From dholmes at openjdk.java.net  Mon Jun 13 11:46:09 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Jun 2022 11:46:09 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v6]
In-Reply-To: <OiUR-GxZJuELeVCJQ5c9RCW2A2W-riXa9Lb1Iplt-FE=.a8b94e59-2157-428f-a8ab-4ae159a5f9c7@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
 <OiUR-GxZJuELeVCJQ5c9RCW2A2W-riXa9Lb1Iplt-FE=.a8b94e59-2157-428f-a8ab-4ae159a5f9c7@github.com>
Message-ID: <gK8jo9ENN3qaw2ceU32Zl-mL-9TURzyWsuV2TR9UIQc=.b744bfe1-860f-4d7a-838c-05e056a16aa2@github.com>

On Mon, 13 Jun 2022 07:45:41 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move assert up and remove other assert, remove unused var
>
> The only way to become an active handshaker is to handshake another thread (target), when that happens we verify that target is ThreadsList safe.
> Thus active handshaker is guaranteed that the target is already verified on a ThreadsList.
> As long as we are the active handshake the target is blocked, i.e. target is safepoint safe.
> 
> The reason I think handshake safe is good is because we have 3 (4) cases:
> 1: Current != Target (Not 3 and not 4)
> 2: Current == Target
> 3: Current != Target, but already executing a handshake for target
> 4: Current != Target, but we are in a safepoint (still no internally handled)

@robehn can you explain to me how the current thread can both be the active handshaker of the target _and_ at the same time be executing another handshake with the target? This is making my head spin.

This change has deviated quite considerably from the issue that caused a bug to be filed. And Dan still has concerns that the current thread should still be protected by a TLH even if not strictly necessary. Maybe we actually need to backtrack and restore an invariant that there is always a TLH even for the current thread and fix the JVMTI code that did things differently?

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 11:46:52 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:52 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

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

  remove VS2005 comment in adlc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/e97c8329..97659965

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9105&range=01-02

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

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

From mbaesken at openjdk.java.net  Mon Jun 13 11:46:53 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 11:46:53 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]
In-Reply-To: <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <291Ty-l04vnkocv-fO0FdNavhFB86R9D2NohNhAt5IU=.d6528332-59b9-4b7d-8bf1-a46a7edd3805@github.com>
 <SUUtDTu4nJk6ynOPqW1O8zG3ESs1fz9D2hFy5qjqTHM=.94191838-3212-4261-ac0b-4e4f26e2dc9d@github.com>
Message-ID: <--XzEepPg2J69xcO4_8XjnUr6zUwWrbRFvw3Y87zEV8=.69b1d008-159c-49f3-a685-4115e4d6d53d@github.com>

On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
> 
>> 489: }
>> 490: 
>> 491: // VS2005 has its own definition, identical to this one.
> 
> Let's adjust comment too. No need to mention VS2005.

Thanks for the hint, I removed the VS2005 related comment.

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

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

From jiefu at openjdk.java.net  Mon Jun 13 11:53:05 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 11:53:05 GMT
Subject: RFR: 8288282: Zero-release build is broken after JDK-8279047 due
 to UseHeavyMonitors is read-only [v2]
In-Reply-To: <vGW9DqfnKmIZQliwhWlMHWBEeHoDWbxU93JO9JY65gE=.e4c55838-7f0e-4660-9c34-d8e75d824b8f@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
 <8kJLYC43RaSYf6EqoZ5o1bNCjcO4KmN1pFZroTBqF6M=.031079e5-0a29-48f8-a325-782839260ced@github.com>
 <_HOnlC058HE0vzssD5PqdVLV_Y9z6MPFxSmx7hwj1Sc=.ecb82b42-16af-46ef-a394-7c50fb9915de@github.com>
 <xcYjoOhlhWXYXKQAAprJ4j9EIhuToyuJvMfsZelGcds=.18c69c16-5f02-416c-a151-942586809e72@github.com>
 <jp2bYGAZhLcoB32S6ZUlyaW48JfqQ5NIO_zIP0hrfWs=.0816acff-4908-4750-90d7-ea738e6987ba@github.com>
 <cijIf8QYREzRcFuymZM0fe6RWigZ_r6WZZCvWUMVutk=.0e47d17e-1587-45a2-ab72-03d6449b5202@github.com>
 <uAVEwO-svQkbo_0dVRDOxU0ekgHKgtCG1nUJ5iGfJ3k=.627d539b-f6f1-4fae-b936-955f750700d8@github.com>
 <vGW9DqfnKmIZQliwhWlMHWBEeHoDWbxU93JO9JY65gE=.e4c55838-7f0e-4660-9c34-d8e75d824b8f@github.com>
Message-ID: <pbomnCE7QD4qyKfZiZeaCkE_Zes4zOhzNMHa9htXQ2s=.0376e0c5-ed15-4c76-a078-0a32ac66c155@github.com>

On Mon, 13 Jun 2022 11:25:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> > Let's not force VM into different option settings in `release` and `fastdebug`, that's just calling for trouble.
>>> 
>>> So what's the trouble would be?
>>> There are many VM flags which are only available for debug VMs.
>> 
>> Those flags are usually having the same value for release and debug VMs. Your current patch changes the flag values depending on VM mode, which exposes potentially different behaviors depending on VM mode. Imagine chasing a bug in `release` VM that does not reproduce in `debug` VM, those are not fun. Let's not do that. It would be all around easier and safer. to just disable to flag in all VM modes.
>> 
>> The block your patch is modifying is added by me in JDK-8273486, I say we just redo it without involving `UseHeavyMonitors` at all, and just disable the test that is affected by it.
>
> It made more sense to me to keep what was the existing debug behaviour, but I don't have any interest in Zero at all, so whatever you want to do @shipilev is fine by me.

Thanks @dholmes-ora and @shipilev for the review.

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

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

From mdoerr at openjdk.java.net  Mon Jun 13 12:41:29 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 12:41:29 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v4]
In-Reply-To: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
Message-ID: <4TUp96D4XdVXbjdz7_qzJk1myrzI7YdwG1sXHazRt6I=.fe76743d-03f1-442d-ab79-f27090eeb8f4@github.com>

> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.

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

  Add comment.

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/3/files
  - new: https://git.openjdk.org/jdk19/pull/3/files/63dc3c61..120c2b1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk19&pr=3&range=02-03

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

PR: https://git.openjdk.org/jdk19/pull/3

From mdoerr at openjdk.java.net  Mon Jun 13 12:41:30 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 12:41:30 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v3]
In-Reply-To: <ZfXhxgSFvgybHSdrL_yzsH96PBiOjKHsezGIsl62uBw=.9ce75b8d-97dd-4f12-8f4c-759fe91c60b8@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <-ckt6BLyFE3bl34L2kG9qkjN9gQrxIZMYlSt2Jqy6Hs=.30a4b312-609f-4dd4-8126-c245f57ad34a@github.com>
 <ZfXhxgSFvgybHSdrL_yzsH96PBiOjKHsezGIsl62uBw=.9ce75b8d-97dd-4f12-8f4c-759fe91c60b8@github.com>
Message-ID: <23kc5rqKbZOINJ9OIKh3U-PY5g89kIulJ8E4EBhvVAg=.73b416f7-76a9-4f79-b051-274e617e0558@github.com>

On Mon, 13 Jun 2022 11:27:40 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify frame(void* sp, void* fp, void* pc).
>
> src/hotspot/cpu/ppc/frame_ppc.cpp line 397:
> 
>> 395: #ifndef PRODUCT
>> 396: // This is a generic constructor which is only used by pns() in debug.cpp.
>> 397: frame::frame(void* sp, void* fp, void* pc) : frame((intptr_t*)sp, (address)pc) {}
> 
> You might add a comment that fp is dropped intensionally.  Only a nice to have ...

Comment added. Thanks for the review!

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

PR: https://git.openjdk.org/jdk19/pull/3

From mbaesken at openjdk.java.net  Mon Jun 13 12:59:13 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 13 Jun 2022 12:59:13 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v4]
In-Reply-To: <4TUp96D4XdVXbjdz7_qzJk1myrzI7YdwG1sXHazRt6I=.fe76743d-03f1-442d-ab79-f27090eeb8f4@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <4TUp96D4XdVXbjdz7_qzJk1myrzI7YdwG1sXHazRt6I=.fe76743d-03f1-442d-ab79-f27090eeb8f4@github.com>
Message-ID: <1KbjcavfGtrQWqUvtRdpR2HiXZEVTX_hV5qQiF3vCwQ=.27d045bd-9bd0-4d27-830d-c5fb32944aee@github.com>

On Mon, 13 Jun 2022 12:41:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
>> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment.

Marked as reviewed by mbaesken (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/3

From jiefu at openjdk.java.net  Mon Jun 13 14:42:09 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 13 Jun 2022 14:42:09 GMT
Subject: Integrated: 8288282: Zero-release build is broken after JDK-8279047
 due to UseHeavyMonitors is read-only
In-Reply-To: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
References: <Mr46H1e6hgb_ScP0QlFPWX67k0SMEfw9MLSjqvijvbI=.e6bc5c8e-0259-4c89-bb4c-a2fbe8b5cc86@github.com>
Message-ID: <9kafPGpRLT75SrJOYFJB_BGEGPRezyZlE-SOhg75hrw=.a393725b-aa79-4b06-a36f-6c793385f442@github.com>

On Sat, 11 Jun 2022 15:08:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Zero-release build is broken after JDK-8279047.
> After JDK-8279047, `UseHeavyMonitors` becomes read-only in PRODUCT VMs.
> 
> But for Zero, `UseHeavyMonitors` needs to be reset if `DiagnoseSyncOnValueBasedClasses != 0`.
> 
>   // If lock diagnostics is needed, always call to runtime
>   if (DiagnoseSyncOnValueBasedClasses != 0) {
>     FLAG_SET_DEFAULT(UseHeavyMonitors, true);
>   }
> 
> 
> I never hear that people would DiagnoseSyncOnValueBasedClasses with zero vms.
> So in order to expire `UseHeavyMonitors` for all PRODUCT VMs, I suggest disabling lock diagnostics for zero vms.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 4aede33f
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aede33fbf940290bb86ac1af1e833ce4d709100
Stats:     6 lines in 2 files changed: 2 ins; 0 del; 4 mod

8288282: Zero-release build is broken after JDK-8279047 due to UseHeavyMonitors is read-only

Reviewed-by: dholmes, shade

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

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

From mdoerr at openjdk.java.net  Mon Jun 13 14:47:08 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 14:47:08 GMT
Subject: Integrated: 8288105: [PPC64] Problems with -XX:+VerifyStack
In-Reply-To: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
Message-ID: <-vEVjwWQBWPDsHf_fLVuB0BVNtW5pLLqo5TDdjYSLQU=.e6bde4d6-b645-4969-8259-b91f50b6cb33@github.com>

On Fri, 10 Jun 2022 10:29:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.

This pull request has now been integrated.

Changeset: 7aafc69a
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/7aafc69a96cc5c2899d9930bcb81ae4cd0319d5c
Stats:     67 lines in 4 files changed: 10 ins; 39 del; 18 mod

8288105: [PPC64] Problems with -XX:+VerifyStack

Reviewed-by: goetz, mbaesken

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

PR: https://git.openjdk.org/jdk19/pull/3

From mdoerr at openjdk.java.net  Mon Jun 13 14:43:17 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 13 Jun 2022 14:43:17 GMT
Subject: RFR: 8288105: [PPC64] Problems with -XX:+VerifyStack [v4]
In-Reply-To: <4TUp96D4XdVXbjdz7_qzJk1myrzI7YdwG1sXHazRt6I=.fe76743d-03f1-442d-ab79-f27090eeb8f4@github.com>
References: <yKlmXkbRmtCCNqmmHW_JCT9i_ppU_mq2rNK0TmLVvs0=.9011a540-8f36-47ab-96cd-f6e96aea021e@github.com>
 <4TUp96D4XdVXbjdz7_qzJk1myrzI7YdwG1sXHazRt6I=.fe76743d-03f1-442d-ab79-f27090eeb8f4@github.com>
Message-ID: <84K8ulmVTZtlwBqdjLgtYmGWFbqkbC7cHKDmjnNMPJc=.e39727b1-db57-473d-92f1-96aa876fbae8@github.com>

On Mon, 13 Jun 2022 12:41:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Deoptimization and uncommon trap stubs require last Java PC to point to a PC which has an appropriate OopMap. Otherwise, -XX:+VerifyStack does no longer work after [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161).
>> I had to debug through the frame stuff and I made the code a bit more robust and easier to use and debug.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment.

Thanks for the reviews!

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

PR: https://git.openjdk.org/jdk19/pull/3

From jvernee at openjdk.java.net  Mon Jun 13 15:06:20 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 13 Jun 2022 15:06:20 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
Message-ID: <QxqJORhigaQ2kCM5aGVUBykuiAAI0QCUQ7WnFU3EqPg=.88ec6f72-3d1e-4c53-b8d5-d92ce77d3e3d@github.com>

On Fri, 10 Jun 2022 09:38:09 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with some nit fixes

Sorry, one more thing

src/hotspot/share/runtime/deoptimization.cpp line 1848:

> 1846:     bool is_osr = nm->is_osr_method();
> 1847:     ls.print("cid=%d%s level=%d",
> 1848:              nm->compile_id(), (is_osr ? " osr" : ""), nm->comp_level());

I'd like to suggest using `%4d` for the cid (also used by PrintCompilation), as well as using spaces for if a method is not osr. That way, the method names will be aligned in the output.

 Also, right now there is no space between the level and method name.
Suggestion:

    ls.print("cid=%4d %s level=%d ",
             nm->compile_id(), (is_osr ? "osr" : "   "), nm->comp_level());

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

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

From duke at openjdk.java.net  Tue Jun 14 00:32:24 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 14 Jun 2022 00:32:24 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v3]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <kHNZMo5ZoHxU--J0NIq3PAQ_LGCTqfGIMqBrx68euAk=.a74525f6-4dcc-4f11-b208-dee160805374@github.com>

> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
> 
> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
> 
> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
> 
> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
> 
> Thanks in advance,
> Cesar

Cesar Soares has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - update with master
 - fix last minute typo
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - ... and 13 more: https://git.openjdk.org/jdk/compare/a9c2ab67...fbb8cb1c

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

Changes: https://git.openjdk.org/jdk/pull/9074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=02
  Stats: 2392 lines in 48 files changed: 117 ins; 331 del; 1944 mod
  Patch: https://git.openjdk.org/jdk/pull/9074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9074/head:pull/9074

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

From jwilhelm at openjdk.java.net  Tue Jun 14 00:33:08 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 14 Jun 2022 00:33:08 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <Bwac7Vn6S44m20ZBCGBw-9InBuCYG230OBoID_-DrVs=.e2267958-4cf0-48fe-b597-6c6953a65ab9@github.com>
References: <Bwac7Vn6S44m20ZBCGBw-9InBuCYG230OBoID_-DrVs=.e2267958-4cf0-48fe-b597-6c6953a65ab9@github.com>
Message-ID: <FI9OLGGzDeFyAI0heWi5xT-puDshGXD4JGoFKLplF3w=.0584a3ec-80a0-442b-9926-b6bef07d9e1d@github.com>

On Mon, 13 Jun 2022 22:34:49 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 19043538
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19043538e100f3646802c2f571dd9c5c67e7f90d
Stats:     72 lines in 5 files changed: 13 ins; 39 del; 20 mod

Merge

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

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

From sspitsyn at openjdk.java.net  Tue Jun 14 02:30:02 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 14 Jun 2022 02:30:02 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v6]
In-Reply-To: <gK8jo9ENN3qaw2ceU32Zl-mL-9TURzyWsuV2TR9UIQc=.b744bfe1-860f-4d7a-838c-05e056a16aa2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <Fatbl-bICvV8qURe0epRNhbwDNJM4aDCp_ppXwu19b0=.b470613d-9df2-4ee1-ace0-3905b2aa5d6e@github.com>
 <OiUR-GxZJuELeVCJQ5c9RCW2A2W-riXa9Lb1Iplt-FE=.a8b94e59-2157-428f-a8ab-4ae159a5f9c7@github.com>
 <gK8jo9ENN3qaw2ceU32Zl-mL-9TURzyWsuV2TR9UIQc=.b744bfe1-860f-4d7a-838c-05e056a16aa2@github.com>
Message-ID: <97FciRfANB33Ft9msGe65KsIQggYvGGGbsjWx-Kq0jQ=.e4cff9de-df07-4ceb-aa90-7c5deba28111@github.com>

On Mon, 13 Jun 2022 11:42:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Maybe we actually need to backtrack and restore an invariant that there is always a TLH even for the current thread and fix the JVMTI code that did things differently?

This will make JVMTI code unnecessarily ugly in a couple of spots.
But I'm okay with that if keeping this invariant is important.
I can help with fixing JVMTI if needed.

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

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

From duke at openjdk.java.net  Tue Jun 14 03:56:47 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 14 Jun 2022 03:56:47 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v4]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>

> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
> 
> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
> 
> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
> 
> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
> 
> Thanks in advance,
> Cesar

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

  fix merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9074/files
  - new: https://git.openjdk.org/jdk/pull/9074/files/fbb8cb1c..8ebb3dca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=02-03

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

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

From alanb at openjdk.java.net  Tue Jun 14 06:30:07 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 06:30:07 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <sEbe6wKIuYDQ3V1dLiA_jOhFMrIFDI6apu9qFIZ6ve4=.09a5602c-b1f3-4c6c-8c40-cae6d44f7112@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

@sspitsyn @lmesnik If I read this correctly then this calling JVMTI GetFrameCount or GetStackTrace with a jthread to a virtual thread that is not mounted. I'm surprised this wasn't caught by any tests. Should we add tests for these cases?

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

PR: https://git.openjdk.org/jdk19/pull/10

From sspitsyn at openjdk.java.net  Tue Jun 14 07:05:04 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 14 Jun 2022 07:05:04 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <BLO_4IU5CasElZiNRvlAXHYE0LjbvCSVYrgMaszAw80=.188d701b-9093-4e98-994b-100e939d66d8@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

Looks good.
Thank you for catching and fixing it.
-Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/10

From sspitsyn at openjdk.java.net  Tue Jun 14 07:16:59 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 14 Jun 2022 07:16:59 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <BLO_4IU5CasElZiNRvlAXHYE0LjbvCSVYrgMaszAw80=.188d701b-9093-4e98-994b-100e939d66d8@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
 <BLO_4IU5CasElZiNRvlAXHYE0LjbvCSVYrgMaszAw80=.188d701b-9093-4e98-994b-100e939d66d8@github.com>
Message-ID: <2sRfWzs-F8BlixVhaAelcOdxEULgpD-jQbhmgFkkk_A=.c2ceb69b-a983-431a-99d2-f98a21e79ec8@github.com>

On Tue, 14 Jun 2022 07:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`
>
> Looks good.
> Thank you for catching and fixing it.
> -Serguei

> @sspitsyn @lmesnik If I read this correctly then this calling JVMTI GetFrameCount or GetStackTrace with a jthread to a virtual thread that is not mounted. I'm surprised this wasn't caught by any tests. Should we add tests for these cases?

I think we have good enough test coverage for these two JVMTI functions (will double-check tomorrow).
I hope that Leonid can confirm the same.
Probably, we do not see the existing tests failing because, the functions:

JvmtiEnvBase::get_stack_trace(javaVFrame *jvf,
                              jint start_depth, jint max_count,
                              jvmtiFrameInfo* frame_buffer, jint* count_ptr)

and
` JvmtiEnvBase::get_frame_count(javaVFrame *jvf)`

never use `this` parameter. So, they could be made static.
The same can be true for overloaded JavaThread based functions.

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

PR: https://git.openjdk.org/jdk19/pull/10

From mbaesken at openjdk.java.net  Tue Jun 14 07:18:08 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 07:18:08 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <F8p1pl8Xqp0YUWSM2CVv6dOYOmi4JfzNLPDm_kDEgXg=.7fd59069-da46-46f5-b23a-3c0c8776b933@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Hi Phil and Andrey are you fine with the current version of the PR ?

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

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

From aturbanov at openjdk.java.net  Tue Jun 14 07:37:05 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 07:37:05 GMT
Subject: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]
In-Reply-To: <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
 <7Ep2pzeiYSx4eA1UNVNTnPLNBskrORoTRlvEJy4votc=.3a6c781b-378f-4da6-b575-7cd325e684d5@github.com>
Message-ID: <PRMkbDt9F0wzGz15GXiw_jJCfpW7NHXz9ntnsRAFwT4=.6627e221-f9a1-48ca-8ee5-a5ea3db846f6@github.com>

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Marked as reviewed by aturbanov (Committer).

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

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

From dholmes at openjdk.java.net  Tue Jun 14 07:45:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 07:45:48 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <cRRQxpVQBo7jl41g8ofm0VmeejNNC565kL2R_zXtuRk=.81e6728b-24d9-463c-852f-3dbf4d5e80ef@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

I'm confused by the comments above. The code failed to initialize the `_env` member but then makes calls via this uninitialized pointer! Surely we should have crashed?

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

PR: https://git.openjdk.org/jdk19/pull/10

From alanb at openjdk.java.net  Tue Jun 14 08:36:58 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 08:36:58 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <cRRQxpVQBo7jl41g8ofm0VmeejNNC565kL2R_zXtuRk=.81e6728b-24d9-463c-852f-3dbf4d5e80ef@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
 <cRRQxpVQBo7jl41g8ofm0VmeejNNC565kL2R_zXtuRk=.81e6728b-24d9-463c-852f-3dbf4d5e80ef@github.com>
Message-ID: <PBXH3S5cpH1_RXIe5LsNUnEsTjoYgpIwMTMo_r64VRg=.e03d6a7e-4fc0-4be3-aeec-cb9395f618a8@github.com>

On Tue, 14 Jun 2022 07:42:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm confused by the comments above. The code failed to initialize the `_env` member but then makes calls via this uninitialized pointer! Surely we should have crashed?

JvmtiEnvBase::get_frame_count is static and I think `((JvmtiEnvBase*)_env)->get_frame_count(_vthread_h(), _count_ptr);` is compiled to just call it and the not-initialised _env is not used.

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

PR: https://git.openjdk.org/jdk19/pull/10

From duke at openjdk.java.net  Tue Jun 14 09:09:00 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 09:09:00 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <QxqJORhigaQ2kCM5aGVUBykuiAAI0QCUQ7WnFU3EqPg=.88ec6f72-3d1e-4c53-b8d5-d92ce77d3e3d@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
 <QxqJORhigaQ2kCM5aGVUBykuiAAI0QCUQ7WnFU3EqPg=.88ec6f72-3d1e-4c53-b8d5-d92ce77d3e3d@github.com>
Message-ID: <DN8-bAYjSxF4LAP8fWkIM5nfZ0BiYtQkAGbnc_S22sE=.bd05639e-75fa-4cb3-b3d3-50fa9aa62f3c@github.com>

On Mon, 13 Jun 2022 14:40:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with some nit fixes
>
> src/hotspot/share/runtime/deoptimization.cpp line 1848:
> 
>> 1846:     bool is_osr = nm->is_osr_method();
>> 1847:     ls.print("cid=%d%s level=%d",
>> 1848:              nm->compile_id(), (is_osr ? " osr" : ""), nm->comp_level());
> 
> I'd like to suggest using `%4d` for the cid (also used by PrintCompilation), as well as using spaces for if a method is not osr. That way, the method names will be aligned in the output.
> 
>  Also, right now there is no space between the level and method name.
> Suggestion:
> 
>     ls.print("cid=%4d %s level=%d ",
>              nm->compile_id(), (is_osr ? "osr" : "   "), nm->comp_level());

Sounds good, fixed.

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

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

From duke at openjdk.java.net  Tue Jun 14 09:08:55 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 09:08:55 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v10]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
> 
> 
> Passes tier1.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8812/files
  - new: https://git.openjdk.org/jdk/pull/8812/files/864460f9..4f488d95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=08-09

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

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

From duke at openjdk.java.net  Tue Jun 14 09:08:57 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 09:08:57 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <WemGXpoypkLymrvTd5FtT90JcayIMC7rwWgIVAtvIag=.cbaf9463-4daa-48ad-aef0-146076bf8ef8@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <ooh3NQ_wFL3lIaOlLoIKinz0nOiqXZ0RUnUP26EVPf8=.dd6b56c1-1ced-4cac-adef-511c4c45c029@github.com>
 <DSZ5ocLdRwdAHJ0xY2UiAhp_jLTBOEVPvjBDoxTv-7E=.996ba85e-0c23-4094-badd-132449139eff@github.com>
 <WemGXpoypkLymrvTd5FtT90JcayIMC7rwWgIVAtvIag=.cbaf9463-4daa-48ad-aef0-146076bf8ef8@github.com>
Message-ID: <Q0vJmiqMSUUpp5KhMJDEJWL2gCT8GDzFUT91SPyschE=.2c0e4d0d-d32c-4a05-bc6e-9e43cc922590@github.com>

On Mon, 13 Jun 2022 16:12:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/deoptimization.cpp line 1841:
>> 
>>> 1839: #endif // INCLUDE_JFR
>>> 1840: 
>>> 1841: void Deoptimization::print_ul(CompiledMethod* nm, Method* tm, intptr_t pc, frame& fr, int trap_bci,
>> 
>> From what I can see, this function only called in this cpp file so it only needs to be defined only in this cpp file.  It doesn't seem to use any Deoptimization class members so doesn't need to be a class member.  Then you can revert changes to deoptimize.hpp.
>
> And can you call it something like log_deopt(), since the "print" function is generally a function that just prints to an outputStream without including logic about logging.

Sounds good, fixed.

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

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

From jvernee at openjdk.java.net  Tue Jun 14 10:18:03 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 14 Jun 2022 10:18:03 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v10]
In-Reply-To: <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
Message-ID: <doaVAChBSPSPZk2-LPOnQNphxcS6fhY-2J0wca7hg_w=.cd9670ae-6d23-4e88-b3b0-290852c2806b@github.com>

On Tue, 14 Jun 2022 09:08:55 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Marked as reviewed by jvernee (Reviewer).

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

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

From mbaesken at openjdk.java.net  Tue Jun 14 10:46:01 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Jun 2022 10:46:01 GMT
Subject: Integrated: JDK-8288094: cleanup old _MSC_VER handling
In-Reply-To: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
References: <DYx0DVtRMhREhAjrh9PmAUfz_lp93Co5nZu7NBK3bCE=.07d294de-8e7a-44fb-84ee-a05d36016336@github.com>
Message-ID: <Wl-mzvch4bCaBlR8_EsYZBVWJJb3r6QJWYOmvWdXMCU=.a1b8b570-16a8-45a0-a2c9-13b29d29ee6f@github.com>

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4 .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also probably older than VS2015) would not be able to build jdk anymore.

This pull request has now been integrated.

Changeset: 0530f4e5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0530f4e517be5d5b3ff10be8a0764e564f068c06
Stats:     163 lines in 9 files changed: 0 ins; 149 del; 14 mod

8288094: cleanup old _MSC_VER handling

Reviewed-by: mdoerr, clanger, aturbanov

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

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

From coleenp at openjdk.java.net  Tue Jun 14 12:17:08 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Jun 2022 12:17:08 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v10]
In-Reply-To: <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
Message-ID: <uQCM1TDEy2cIoRgTBnHpSxKRJ3y0EZR1cQunacjL9fg=.8e78ca74-cdb1-44cd-aaa0-1ce465f9bbd1@github.com>

On Tue, 14 Jun 2022 09:08:55 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Just a couple of small tweaks. Thanks.

src/hotspot/share/runtime/deoptimization.cpp line 1841:

> 1839: #endif // INCLUDE_JFR
> 1840: 
> 1841: void log_deopt(CompiledMethod* nm, Method* tm, intptr_t pc, frame& fr, int trap_bci,

Add 'static' keyword so it has internal linkage.

src/hotspot/share/runtime/deoptimization.hpp line 47:

> 45:   friend class EscapeBarrier;
> 46: 
> 47:  public:

You can revert changes to this file since this wasn't part of your change.  Somebody can fix this some other time when they're changing this file.

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

Changes requested by coleenp (Reviewer).

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

From rehn at openjdk.java.net  Tue Jun 14 13:45:10 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 14 Jun 2022 13:45:10 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <kv1RjlWhaJUpznOU-hyxRIBcII_-K70Fd8LfowueC08=.5e362621-83ca-4861-b4a0-b2abc138d4d1@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

Looks fine to me, just make sure it passes JCK.

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

Marked as reviewed by rehn (Reviewer).

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

From duke at openjdk.java.net  Tue Jun 14 13:46:58 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 13:46:58 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v11]
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <nOGwKcu_G5KP0pTBdqRztSyTXWxr6AlvOxjoDJ__NbY=.15ff585f-ec08-4c12-9d9b-f58f53126041@github.com>

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
> 
> 
> Passes tier1.

Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:

 - Revert my changes to deoptimization.hpp
 - Declare log_deopt static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8812/files
  - new: https://git.openjdk.org/jdk/pull/8812/files/4f488d95..76ff7483

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=09-10

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

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

From duke at openjdk.java.net  Tue Jun 14 13:52:09 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 13:52:09 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v10]
In-Reply-To: <uQCM1TDEy2cIoRgTBnHpSxKRJ3y0EZR1cQunacjL9fg=.8e78ca74-cdb1-44cd-aaa0-1ce465f9bbd1@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
 <uQCM1TDEy2cIoRgTBnHpSxKRJ3y0EZR1cQunacjL9fg=.8e78ca74-cdb1-44cd-aaa0-1ce465f9bbd1@github.com>
Message-ID: <UQ5_qmN_wJVuHy2a7_Po3Yntfl2XYCbxMj_RX5kLk30=.63dd6d90-04ef-4d90-8d3b-16864b8956ba@github.com>

On Tue, 14 Jun 2022 12:12:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> src/hotspot/share/runtime/deoptimization.cpp line 1841:
> 
>> 1839: #endif // INCLUDE_JFR
>> 1840: 
>> 1841: void log_deopt(CompiledMethod* nm, Method* tm, intptr_t pc, frame& fr, int trap_bci,
> 
> Add 'static' keyword so it has internal linkage.

Fixed.

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

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

From duke at openjdk.java.net  Tue Jun 14 13:52:14 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 14 Jun 2022 13:52:14 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v9]
In-Reply-To: <uQCM1TDEy2cIoRgTBnHpSxKRJ3y0EZR1cQunacjL9fg=.8e78ca74-cdb1-44cd-aaa0-1ce465f9bbd1@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <jci5SOwo6yGc-ane1kinWeGtwNqMLCgyIt9_3eX69g0=.9ce800c6-6800-44a9-aa33-e94e7e342772@github.com>
 <uQCM1TDEy2cIoRgTBnHpSxKRJ3y0EZR1cQunacjL9fg=.8e78ca74-cdb1-44cd-aaa0-1ce465f9bbd1@github.com>
Message-ID: <QuUB0kgeLUvgJcZSh4q3dHSucmjVnbyi1p8zVk_685Y=.ac92e957-c76e-446d-9bfa-00b8eec8cca7@github.com>

On Tue, 14 Jun 2022 12:13:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update with some nit fixes
>
> src/hotspot/share/runtime/deoptimization.hpp line 47:
> 
>> 45:   friend class EscapeBarrier;
>> 46: 
>> 47: 
> 
> You can revert changes to this file since this wasn't part of your change.  Somebody can fix this some other time when they're changing this file.

Reverted.

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

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

From coleenp at openjdk.java.net  Tue Jun 14 14:01:50 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Jun 2022 14:01:50 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <fVxNjxAjgFVwCdQ5OcytbKwm9HGW6UbC3bp7Tn6c0yY=.6c242970-59e5-4372-b62c-7f0a11a997be@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

Thanks Robbin.  yes it passes the JCK both locally and in our mach5 test system.

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

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

From coleenp at openjdk.java.net  Tue Jun 14 15:03:16 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Jun 2022 15:03:16 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v11]
In-Reply-To: <nOGwKcu_G5KP0pTBdqRztSyTXWxr6AlvOxjoDJ__NbY=.15ff585f-ec08-4c12-9d9b-f58f53126041@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <nOGwKcu_G5KP0pTBdqRztSyTXWxr6AlvOxjoDJ__NbY=.15ff585f-ec08-4c12-9d9b-f58f53126041@github.com>
Message-ID: <FyI4yYuBy1OcpfkcE7RwapjVFRKin9mKUsIm1WhSEjo=.09785d54-c2dd-4263-92f8-6fb5250101fa@github.com>

On Tue, 14 Jun 2022 13:46:58 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert my changes to deoptimization.hpp
>  - Declare log_deopt static

Perfect!  Thank you.

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

Marked as reviewed by coleenp (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Jun 14 16:03:19 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 14 Jun 2022 16:03:19 GMT
Subject: RFR: 8242181: [Linux] Show source information when printing native
 stack traces in hs_err files [v12]
In-Reply-To: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
References: <b4LpGSdAhQPw3hzU9p273wI1RNp8jU2atUwgPbCN1yc=.7662be04-acc8-48eb-8d0e-b2e6e10d1e59@github.com>
Message-ID: <4Eha34Wka66ssPeJb4oEPphesBlxVrXmElPboudLK4s=.faa049f4-3c53-485c-812a-f36ae6d5c32c@github.com>

> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method:
> 
> Stack: [0x00007f6e01739000,0x00007f6e0183a000],  sp=0x00007f6e01838110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f
> 
> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method.
> 
> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)):
> 
> Stack: [0x00007f34fca18000,0x00007f34fcb19000],  sp=0x00007f34fcb17110,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x620d86]  Compilation::~Compilation()+0x64  (c1_Compilation.cpp:607)
> V  [libjvm.so+0x624b92]  Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec  (c1_Compiler.cpp:250)
> V  [libjvm.so+0x8303ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899  (compileBroker.cpp:2291)
> V  [libjvm.so+0x82f067]  CompileBroker::compiler_thread_loop()+0x3df  (compileBroker.cpp:1966)
> V  [libjvm.so+0x84f0d1]  CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69  (compilerThread.cpp:59)
> V  [libjvm.so+0x1209329]  JavaThread::thread_main_inner()+0x15d  (thread.cpp:1297)
> V  [libjvm.so+0x12091c9]  JavaThread::run()+0x167  (thread.cpp:1280)
> V  [libjvm.so+0x1206ada]  Thread::call_run()+0x180  (thread.cpp:358)
> V  [libjvm.so+0x1012e55]  thread_native_entry(Thread*)+0x18f  (os_linux.cpp:705)
> 
> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. 
> 
> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf
> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. 
> 
> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability.
> 
> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. 
> 
> **Testing:**
> Apart from manual testing, I've added two kinds of tests:
> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers.
> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename.
> 
> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation.
> 
> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional  `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number.
> 
> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user).
> 
> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`!
>  
> Thanks,
> Christian

Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:

 - Exclude TestDwarf.java when run with product because TraceDwarf is a develop flag
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix TestDwarf for older GCC versions
 - Change logging from UL to tty based with new TraceDwarfLevel develop flag
 - Add support to parse the .debug_line section in DWARF 2 as emitted by GCC 8, add some comments
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Merge branch 'master' into JDK-8242181
 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions
 - ... and 58 more: https://git.openjdk.org/jdk/compare/c2ccf4ca...cb030f10

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

Changes: https://git.openjdk.org/jdk/pull/7126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=11
  Stats: 2781 lines in 18 files changed: 2684 ins; 41 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/7126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7126/head:pull/7126

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

From vlivanov at openjdk.java.net  Tue Jun 14 18:14:43 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 14 Jun 2022 18:14:43 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <Zfu8lxcOz1XRDELewThETsSn0aD24eyZjpbmEV2Y9_4=.17c19158-3a31-4498-a051-e449113ba604@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From coleenp at openjdk.java.net  Tue Jun 14 19:40:42 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Jun 2022 19:40:42 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <N1rETlWl1H7atdHLYvrKfpUzTcOTV7vHiXf-TTfBMp0=.adbca6b3-6069-4a88-a31a-11ac9c59c2f1@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

Thanks Vladimir and thank you for your help with the CodeCache::flush_dependencies() logic.

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

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

From dholmes at openjdk.java.net  Tue Jun 14 23:21:39 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 23:21:39 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <Vs1cSPMJimt4uYZyW5pTA-GaNYYENHGLqZ1_G-tIfAE=.a43846a1-bcc9-4c35-b296-71c2d7bb1552@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

src/hotspot/share/oops/cpCache.cpp line 269:

> 267:     if (invoke_code == Bytecodes::_invokestatic) {
> 268:       assert(method->method_holder()->is_initialized() ||
> 269:              method->method_holder()->is_reentrant(Thread::current()),

Please change this back - `is_reentrant` has no meaning by itself, reentrant with respect to what?

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

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

From dholmes at openjdk.java.net  Tue Jun 14 23:27:37 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 23:27:37 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <tQhU-sY-1XLYj2j6Om2arieqfN61Z3g4eqXhhH7TvPM=.bf37ff56-e907-4ee0-8a8d-b8887da267ac@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

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

> 1177: 
> 1178:   // Now flush all code that assume the class is not linked.
> 1179:   // Set state under the Compile_lock also.

Wow! Why do we have to do this now?

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

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

From dholmes at openjdk.java.net  Tue Jun 14 23:33:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 23:33:36 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <lu8lToc2SCTahmfvSPpmMrpUi5ocfPwn-CXRN_zdNLo=.eab7d030-abe5-4dc3-a48e-7ec289f34a67@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

src/hotspot/share/runtime/vframe.cpp line 231:

> 229:     else if (thread()->osthread()->get_state() == CONDVAR_WAIT) {
> 230:       // We are waiting on an Object monitor but Object.wait() isn't the
> 231:       // top-frame, so we should be waiting on a Class initialization monitor.

Comment needs updating. I'm glad to see this still works okay with such a simple change.

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

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

From kbarrett at openjdk.java.net  Wed Jun 15 00:58:50 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 15 Jun 2022 00:58:50 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v11]
In-Reply-To: <y68-_KhDjjDu5oThDBs4L8CbV3zOL0KYM8lFmNnm2Qc=.e8a231b6-3cee-4de6-a5d0-83d14aadbf1c@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <y68-_KhDjjDu5oThDBs4L8CbV3zOL0KYM8lFmNnm2Qc=.e8a231b6-3cee-4de6-a5d0-83d14aadbf1c@github.com>
Message-ID: <hGe-pAhdrPKPQ1ZRiHiaD6Fj-D4VZKcR06G5DVra9cw=.63ea5b45-82e6-4a8a-9347-7b759b413f34@github.com>

On Mon, 23 May 2022 07:22:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert my changes to deoptimization.hpp
>>  - Declare log_deopt static
>
> src/hotspot/share/runtime/deoptimization.cpp line 1937:
> 
>> 1935:     if(Log(deoptimization)::is_info()) {
>> 1936:       LogMessage(deoptimization) lm;
>> 1937:       auto tm = trap_method();
> 
> Not sure use if C++11 type inference is a permitted use - I can't find it n the style guide.

[not a review, just responding to @dholmes-ora question]

Search for "Type Deduction" in the style guide.  There aren't a lot of uses, and the guidance is to only use it when there's significant benefit, not just as a convenience to avoid writing the type.

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

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

From kvn at openjdk.java.net  Wed Jun 15 01:59:43 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 15 Jun 2022 01:59:43 GMT
Subject: RFR: 8284849: Add deoptimization to unified logging [v11]
In-Reply-To: <nOGwKcu_G5KP0pTBdqRztSyTXWxr6AlvOxjoDJ__NbY=.15ff585f-ec08-4c12-9d9b-f58f53126041@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
 <nOGwKcu_G5KP0pTBdqRztSyTXWxr6AlvOxjoDJ__NbY=.15ff585f-ec08-4c12-9d9b-f58f53126041@github.com>
Message-ID: <6BPR-gtfjiWYHIdOe1VaVOMQMnBSgl-ScyfqKvEAQps=.a055d9e2-2318-4bb0-b9a7-5ef07eed3fab@github.com>

On Tue, 14 Jun 2022 13:46:58 GMT, Johan Sj?l?n <duke at openjdk.java.net> wrote:

>> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
>> 
>> An example output looks like this: 
>> 
>> 
>> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
>> 
>> 
>> Passes tier1.
>
> Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert my changes to deoptimization.hpp
>  - Declare log_deopt static

Latest version is good.

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

Marked as reviewed by kvn (Reviewer).

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

From coleenp at openjdk.java.net  Wed Jun 15 02:43:40 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Jun 2022 02:43:40 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <Vs1cSPMJimt4uYZyW5pTA-GaNYYENHGLqZ1_G-tIfAE=.a43846a1-bcc9-4c35-b296-71c2d7bb1552@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
 <Vs1cSPMJimt4uYZyW5pTA-GaNYYENHGLqZ1_G-tIfAE=.a43846a1-bcc9-4c35-b296-71c2d7bb1552@github.com>
Message-ID: <1aOHY-8wYb41TmgEQ4IvRgCNUl98rb2-O61l5y-jvZk=.5b6fa2b6-ceb1-4ef3-adf3-2e5fe7741698@github.com>

On Tue, 14 Jun 2022 23:18:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
>> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.
>
> src/hotspot/share/oops/cpCache.cpp line 269:
> 
>> 267:     if (invoke_code == Bytecodes::_invokestatic) {
>> 268:       assert(method->method_holder()->is_initialized() ||
>> 269:              method->method_holder()->is_reentrant(Thread::current()),
> 
> Please change this back - `is_reentrant` has no meaning by itself, reentrant with respect to what?

I can have a is_reentrant_initialization() and an is_reentrant_linking() method if that makes it clearer.

> src/hotspot/share/oops/instanceKlass.cpp line 1179:
> 
>> 1177: 
>> 1178:   // Now flush all code that assume the class is not linked.
>> 1179:   // Set state under the Compile_lock also.
> 
> Wow! Why do we have to do this now?

It's not new, it was moved.

> src/hotspot/share/runtime/vframe.cpp line 231:
> 
>> 229:     else if (thread()->osthread()->get_state() == CONDVAR_WAIT) {
>> 230:       // We are waiting on an Object monitor but Object.wait() isn't the
>> 231:       // top-frame, so we should be waiting on a Class initialization monitor.
> 
> Comment needs updating. I'm glad to see this still works okay with such a simple change.

Oh, yes, it does need updating.

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

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

From duke at openjdk.java.net  Wed Jun 15 03:08:47 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 15 Jun 2022 03:08:47 GMT
Subject: Withdrawn: 8269537: memset() is called after operator new
In-Reply-To: <fe0PJHcDQ9Gax0idlyvpt0IQxhDwReN27jV9en3F1Uo=.6853eda5-c0fe-4664-b231-8e8922fa3713@github.com>
References: <fe0PJHcDQ9Gax0idlyvpt0IQxhDwReN27jV9en3F1Uo=.6853eda5-c0fe-4664-b231-8e8922fa3713@github.com>
Message-ID: <IahewKATJ8dlwBBqv6UHAyrULxUv7O578KfLEFTlhO0=.0be54c8c-aa65-42eb-84b1-3ad0c98ee3fe@github.com>

On Tue, 7 Sep 2021 12:25:54 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The basic problem is that we are relying on undefined behaviour, as documented in the code:
> 
> // This whole business of passing information from ResourceObj::operator new
> // to the ResourceObj constructor via fields in the "object" is technically UB.
> // But it seems to work within the limitations of HotSpot usage (such as no
> // multiple inheritance) with the compilers and compiler options we're using.
> // And it gives some possibly useful checking for misuse of ResourceObj.
> 
> 
> I am removing the undefined behaviour by passing the type of allocation through a thread local variable.
> 
> This solution has some advantages:
> 1) ~it is not UB~
> 2) it is simpler and easier to understand
> 3) it uses less memory (I could make it use even less if I made the enum `allocation_type` a u8)
> 4) in the *very* unlikely situation that stack memory (or embedded) already equals the data calculated from the address of the object, the code will also work. 
> 
> When doing the change, I also updated  `allocated_on_stack()` to the new name `allocated_on_stack_or_embedded()` which is much harder to misinterpret.
> 
> I also disallow to "fake" the memory type by explicitly calling `ResourceObj::set_allocation_type`.
> 
> This forced me to change two places that is faking the allocation type of an embedded `GrowableArray` from  `STACK_OR_EMBEDDED` to `C_HEAP`. The faking of the type is hard to understand as a `STACK_OR_EMBEDDED` `GrowableArray` can allocate any type of object. My guess is that `GrowableArray` has changed behaviour, or maybe that it was hard to understand because the old naming of `allocated_on_stack()`. 
> 
> I have also tried to update the comments. In doing that I not only changed the comments for this change, but also for the *incorrect* advice to always delete object you allocate with new.
> 
> Testing on debug build tier1-3
> Testing on release build tier1

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.java.net  Wed Jun 15 03:28:36 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Jun 2022 03:28:36 GMT
Subject: RFR: 8288064: Class initialization locking [v2]
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <iNopn-OFagKGOrLiBbbz0esUXgMYXWHSvuBO0yB2tXk=.7f38fdb1-9c7c-4b3a-9cfa-59c769dc5ed4@github.com>

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

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

  Review comments from David Holmes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9141/files
  - new: https://git.openjdk.org/jdk/pull/9141/files/bf2c7aee..c393cfb4

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

  Stats: 10 lines in 5 files changed: 1 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9141.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9141/head:pull/9141

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

From coleenp at openjdk.java.net  Wed Jun 15 03:28:37 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Jun 2022 03:28:37 GMT
Subject: RFR: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <0lE7BOXhepLiL2UOGjrbRdrOfV7dAe80KmifoAHfwc4=.36e00c5c-78ec-4d74-bfa0-c4e3ff3d851a@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

Thanks David for your comments. I pushed an update and retested with jck tests.

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

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

From dholmes at openjdk.java.net  Wed Jun 15 06:29:54 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Jun 2022 06:29:54 GMT
Subject: RFR: 8288064: Class initialization locking [v2]
In-Reply-To: <iNopn-OFagKGOrLiBbbz0esUXgMYXWHSvuBO0yB2tXk=.7f38fdb1-9c7c-4b3a-9cfa-59c769dc5ed4@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
 <iNopn-OFagKGOrLiBbbz0esUXgMYXWHSvuBO0yB2tXk=.7f38fdb1-9c7c-4b3a-9cfa-59c769dc5ed4@github.com>
Message-ID: <ChER7VpReNCqhRjrRohqmhdiHO7NfuvLClypeU4H6IM=.ed31c6fc-76b4-4c37-9e1a-8153e3275fb8@github.com>

On Wed, 15 Jun 2022 03:28:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
>> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from David Holmes.

src/hotspot/share/oops/instanceKlass.hpp line 547:

> 545:   bool is_in_error_state() const           { return init_state() == initialization_error; }
> 546:   bool is_reentrant_initialization(Thread *thread) { return thread == _init_thread; }
> 547:   bool is_reentrant_linking(Thread *thread)        { return thread == _init_thread; }

Sorry Coleen when I asked for this I thought these queries included the state check, but now I see the state is checked separately. You may as well just have a single simple query `is_init_thread(JavaThread* current)`.
And wherever we set the `_init_thread` we should have an assert that it is NULL (if not already done). Thanks.

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

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

From dholmes at openjdk.java.net  Wed Jun 15 06:33:46 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Jun 2022 06:33:46 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <PBXH3S5cpH1_RXIe5LsNUnEsTjoYgpIwMTMo_r64VRg=.e03d6a7e-4fc0-4be3-aeec-cb9395f618a8@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
 <cRRQxpVQBo7jl41g8ofm0VmeejNNC565kL2R_zXtuRk=.81e6728b-24d9-463c-852f-3dbf4d5e80ef@github.com>
 <PBXH3S5cpH1_RXIe5LsNUnEsTjoYgpIwMTMo_r64VRg=.e03d6a7e-4fc0-4be3-aeec-cb9395f618a8@github.com>
Message-ID: <ETwCLt26x2KUC9I4XDJ0XP0znK_SY3WLfMz3JuqHv5s=.231f5d64-36a7-4efc-b8d7-3d4e538825de@github.com>

On Tue, 14 Jun 2022 08:33:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I'm confused by the comments above. The code failed to initialize the `_env` member but then makes calls via this uninitialized pointer! Surely we should have crashed?
>
>> I'm confused by the comments above. The code failed to initialize the `_env` member but then makes calls via this uninitialized pointer! Surely we should have crashed?
> 
> JvmtiEnvBase::get_frame_count is static and I think `((JvmtiEnvBase*)_env)->get_frame_count(_vthread_h(), _count_ptr);` is compiled to just call it and the not-initialised _env is not used.

Thanks @AlanBateman !

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

PR: https://git.openjdk.org/jdk19/pull/10

From shade at openjdk.java.net  Wed Jun 15 07:03:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Jun 2022 07:03:45 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <e1sc1BnupNisKkhqhE6dF6j4SfbYx8vot7gzuRZvuEc=.bd2df6ad-4b4f-4ff2-982d-a3b9e7fcbf31@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

Everyone's good with this patch then?

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

PR: https://git.openjdk.org/jdk19/pull/10

From dholmes at openjdk.java.net  Wed Jun 15 07:12:41 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Jun 2022 07:12:41 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <A18UU5g-g7IHFwtkhv2jpit8Ju8YBx8bstJJIcThQhw=.a11fafef-2f6c-4d8b-b3c3-b69129196ed8@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/10

From shade at openjdk.java.net  Wed Jun 15 07:53:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Jun 2022 07:53:38 GMT
Subject: RFR: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <NM0QCvjoIRYXK7Bk4ngYnOaRgayTZa1LtD95iH9ZDV4=.f686e8c3-ac91-4d9e-a665-89eb4547cd6e@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

Excellent, thanks.

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

PR: https://git.openjdk.org/jdk19/pull/10

From shade at openjdk.java.net  Wed Jun 15 07:53:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Jun 2022 07:53:39 GMT
Subject: Integrated: 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
In-Reply-To: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
References: <qpzFl2BlBpbbuvrhrPBnTLplO9sP65lk1vmVhdyxlkY=.5e26f822-4658-4a0d-a63d-e0a53defce71@github.com>
Message-ID: <kD2rv7YdF9XYHoyXOufhGHPBJkjGzpcrp6ewUEEopLQ=.b2b7ab7c-624a-436c-bf00-30d5e98be4d4@github.com>

On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those fields are used, and therefore this is a serious bug. These ops seem to be used only from a few corner cases, which is probably why this was never actually found in testing.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`

This pull request has now been integrated.

Changeset: 31bc6899
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/31bc689977c536d7e6b28020eac1b472b60f7e06
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops

Reviewed-by: sspitsyn, dholmes

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

PR: https://git.openjdk.org/jdk19/pull/10

From bulasevich at openjdk.java.net  Wed Jun 15 09:15:44 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Wed, 15 Jun 2022 09:15:44 GMT
Subject: Integrated: 8287373: remove unnecessary paddings in generated code
In-Reply-To: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
References: <YHOpwdiLl7LXWfdQXT6o3EvctvRZs7BS8UDMlA4IKAg=.ed36653a-71fd-4821-9cea-ea9d5e24a012@github.com>
Message-ID: <YKX_3jaHcjPMEMv3vkAOFsKtJF-i4LjKNmDp7s8uQ8Y=.ab7eac09-2fcf-4a65-bfb3-660fb10284a0@github.com>

On Thu, 28 Apr 2022 14:46:57 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD.
> 
> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH.
> 
> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD.
> 
> Example. Dummy method disassembly on AARCH, before vs after:
> 
> [Verified Entry Point]                          |  [Verified Entry Point]
>   78c63b80:   nop                               |    7437e480:   nop
>   78c63b84:   sub     x9, sp, #0x20, lsl #12    |    7437e484:   sub     x9, sp, #0x20, lsl #12
>   78c63b88:   str     xzr, [x9]                 |    7437e488:   str     xzr, [x9]
>   78c63b8c:   sub     sp, sp, #0x20             |    7437e48c:   sub     sp, sp, #0x20
>   78c63b90:   stp     x29, x30, [sp, #16]       |    7437e490:   stp     x29, x30, [sp, #16]
>   78c63b94:   orr     w1, wzr, #0x10            |    7437e494:   orr     w1, wzr, #0x10
>   78c63b98:   bl      78343e00                  |    7437e498:   bl      73a61980
>   78c63b9c:   .inst   0x00000000 ; undefined    |    7437e49c:   .inst   0x00000000 ; undefined
>   78c63ba0:   .inst   0x00000000 ; undefined    |
>   78c63ba4:   .inst   0x00000000 ; undefined    |
>   78c63ba8:   .inst   0x00000000 ; undefined    |
>   78c63bac:   .inst   0x00000000 ; undefined    |
>   78c63bb0:   .inst   0x00000000 ; undefined    |
>   78c63bb4:   .inst   0x00000000 ; undefined    |
>   78c63bb8:   .inst   0x00000000 ; undefined    |
>   78c63bbc:   .inst   0x00000000 ; undefined    |
> [Stub Code]                                     |  [Stub Code]
>   78c63bc0:   ldr     x8, 78c63bc8              |    7437e4a0:   ldr     x8, 7437e4a8
>   78c63bc4:   br      x8                        |    7437e4a4:   br      x8
>   78c63bc8:   .inst   0x78343e00 ; undefined    |    7437e4a8:   .inst   0x73a61980 ; undefined
>   78c63bcc:   .inst    ; undefined              |    7437e4ac:   .inst    ; undefined
> [Exception Handler]                             |  [Exception Handler]
>   78c63bd0:   b       783ee080                  |    7437e4b0:   b       73b0c100
> [Deopt Handler Code]                            |  [Deopt Handler Code]
>   78c63bd4:   adr     x30, 78c63bd4             |    7437e4b4:   adr     x30, 7437e4b4
>   78c63bd8:   b       78343ac0                  |    7437e4b8:   b       73a61620
>   78c63bdc:   .inst   0x00000000 ; undefined    |    7437e4bc:   .inst   0x00000000 ; undefined

This pull request has now been integrated.

Changeset: 68b20572
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68b2057205844228562f3a0801d70e4a5a04ea85
Stats:     69 lines in 9 files changed: 36 ins; 5 del; 28 mod

8287373: remove unnecessary paddings in generated code

Reviewed-by: kvn

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

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

From duke at openjdk.java.net  Wed Jun 15 12:29:03 2022
From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Wed, 15 Jun 2022 12:29:03 GMT
Subject: Integrated: 8284849: Add deoptimization to unified logging
In-Reply-To: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
References: <sEul9uusXj2fzRgdyeTKgoflWiksQbz62v8xrRBUVzc=.fb81f012-39a3-4424-bea4-043e0dcad06f@github.com>
Message-ID: <qsf-e-BmLqKtWbOOq7rCGQg0TBncCPhpXwEXJRcNmOw=.a5670ed2-f304-4704-b097-c71c35107ecd@github.com>

On Fri, 20 May 2022 14:12:30 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important).
> 
> An example output looks like this: 
> 
> 
> [1.324s][debug][deoptimization] cid=236 level=4java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z trap_bci=26 unstable_if reinterpret pc=0x00007f8b30bf8b94 relative_pc=0x0000000000000174
> 
> 
> Passes tier1.

This pull request has now been integrated.

Changeset: d5cd2f2c
Author:    Johan Sj?l?n <johan.sjolen at oracle.com>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5cd2f2caa857891c2cbc13e7da4f85720f3bbb7
Stats:     41 lines in 2 files changed: 33 ins; 2 del; 6 mod

8284849: Add deoptimization to unified logging

Reviewed-by: jvernee, kvn, xliu, coleenp

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

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

From coleenp at openjdk.java.net  Wed Jun 15 13:44:53 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Jun 2022 13:44:53 GMT
Subject: RFR: 8288064: Class initialization locking [v3]
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <SjD4fnGENdPyyIh6lQIXhz2SCr-GKS_i9EIqIEgVdk4=.598aece6-0792-4b54-bee8-01fc33beb470@github.com>

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

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

  Renamed is_reentrant again and added an assert.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9141/files
  - new: https://git.openjdk.org/jdk/pull/9141/files/c393cfb4..2a50f311

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

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

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

From coleenp at openjdk.java.net  Wed Jun 15 13:44:57 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 15 Jun 2022 13:44:57 GMT
Subject: RFR: 8288064: Class initialization locking [v2]
In-Reply-To: <ChER7VpReNCqhRjrRohqmhdiHO7NfuvLClypeU4H6IM=.ed31c6fc-76b4-4c37-9e1a-8153e3275fb8@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
 <iNopn-OFagKGOrLiBbbz0esUXgMYXWHSvuBO0yB2tXk=.7f38fdb1-9c7c-4b3a-9cfa-59c769dc5ed4@github.com>
 <ChER7VpReNCqhRjrRohqmhdiHO7NfuvLClypeU4H6IM=.ed31c6fc-76b4-4c37-9e1a-8153e3275fb8@github.com>
Message-ID: <U2wMJtRlhkdMs3J7Wvj8U96PzK0NQeZjM4CCsU_Oryk=.f2006e4b-a805-48db-b971-b07dc580968c@github.com>

On Wed, 15 Jun 2022 06:27:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments from David Holmes.
>
> src/hotspot/share/oops/instanceKlass.hpp line 547:
> 
>> 545:   bool is_in_error_state() const           { return init_state() == initialization_error; }
>> 546:   bool is_reentrant_initialization(Thread *thread) { return thread == _init_thread; }
>> 547:   bool is_reentrant_linking(Thread *thread)        { return thread == _init_thread; }
> 
> Sorry Coleen when I asked for this I thought these queries included the state check, but now I see the state is checked separately. You may as well just have a single simple query `is_init_thread(JavaThread* current)`.
> And wherever we set the `_init_thread` we should have an assert that it is NULL (if not already done). Thanks.

Ok, your suggested name change is good and I added the assert we talked about. JCK vm tests pass but I'm rerunning tier1-4 on this change.

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

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I think this looks good overall, but please try to limit the accessibility of  the methods in `State`.

src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:

> 38:  * operations triggered by threads other than the owner thread, which we support.
> 39:  */
> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {

Same here. I don't see why this is made public now.

src/java.base/share/classes/jdk/internal/foreign/SharedSessionState.java line 46:

> 44:  * checking the liveness bit upon access can be performed in plain mode, as in the confined case.
> 45:  */
> 46: public class SharedSessionState extends MemorySessionImpl.State {

Unclear to me why this is now public. It still seems to be only accessed from with the `jdk.internal.foreign` package?

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

Marked as reviewed by jvernee (Reviewer).

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <NNFbp2rnfsp4-twI5e8a6s9kxqklOnUaInu5fAEUr0o=.a87e3023-0dd0-4b29-86b0-38ed8efd4883@github.com>

On Wed, 15 Jun 2022 14:41:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into cleanup_memory_session_impl_state
>>  - Add null check on Buffer::checkState
>>  - Add docs
>>    Simplify liveness check in Buffer
>>    Drop redundant import in DirectBuffer
>>  - Simplify checkValidState
>>  - Add fastpath for implicit session state
>>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>>  - Fix asNonCloseable to return self
>>    Improve direct buffer code with isImplicit predicate
>>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>>  - Simplify readOnly check
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246
>
> src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:
> 
>> 38:  * operations triggered by threads other than the owner thread, which we support.
>> 39:  */
>> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {
> 
> Same here. I don't see why this is made public now.

Same for `justClose` and `ConfinedList::add` in this file. They still seem only accessed in the same package.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 16:55:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 16:55:06 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <lTNs91mKp3yK6ux1HoGYYanROrJMGgwBs_ykF-Us-8Q=.d7350e59-cfa0-4cbe-8d33-fd97e24a4a47@github.com>

On Wed, 15 Jun 2022 14:55:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think this looks good overall, but please try to limit the accessibility of the methods in `State`.

Thanks, I'll take another look

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:31 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <N43DTnhrT-MpOW5fxbWyn5r2x7Fbn0MEZGYREvuCKAQ=.67761ec2-83ef-46c9-a54e-d0487fc233c5@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9017/files
  - new: https://git.openjdk.org/jdk/pull/9017/files/5b8f7246..67710665

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

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:34 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <WOeSkpiMEWFdfq24NPuKr1MkRsC-2KyWl7-xBTVhinY=.cedef75d-3936-4ef1-ba65-a24f579ac63e@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I'm going to close this PR and re-open another against the 19 repo.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:54:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:54:39 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <45yAEXwPWvEqPT03oBHaJgH9HANer_iQ1uDSNGELoiA=.a1e6ee75-275e-407c-a8ce-355f54fab41f@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Address review comments
 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - ... and 6 more: https://git.openjdk.org/jdk/compare/13d4ddc3...b1a494e4

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

Changes: https://git.openjdk.org/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=03
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9017/head:pull/9017

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:01:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:01:08 GMT
Subject: Withdrawn: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <68QEAhgjPyyQCGZ7bKIm4b_sNlrxfpUWblsB5miSHy8=.22c49980-caba-4fd0-87a9-851ee63dadfd@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:16:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:16:21 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>

This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

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

Commit messages:
 - Add missing files
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287809
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From jvernee at openjdk.java.net  Wed Jun 15 22:30:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 22:30:09 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <U4NNFOHiB-6BybfOYNa3eluBB_n05D2jZlLgjcx9G-4=.f929fc9d-2990-474d-81c4-ebdad836bb5a@github.com>

On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

Already reviewed in the mainline repo.

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/22

From ksakata at openjdk.java.net  Thu Jun 16 01:47:39 2022
From: ksakata at openjdk.java.net (Koichi Sakata)
Date: Thu, 16 Jun 2022 01:47:39 GMT
Subject: RFR: 8280472: Don't mix legacy logging with UL
Message-ID: <CS9Ss9ECb-swrKB4RypFmTsW8TlHz8Pr_zJTFAzk9mc=.fc3f348d-730c-4c34-91b7-651c74802b57@github.com>

This PR remove extra conditions related to Unified Logging.

Those conditions have been left after the transition to Unified Logging. This is an only place that uses UL, Verbose and WizardMode flags together. This JBS issue suggests to remove those flags.

# Details
At present to output target log messages needs the debug build of OpenJDK and, Verbose or WizardMode option.

$ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -XX:+Verbose -version
(Omitted)
[0.090s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
[0.090s][info][methodhandles] {method}
[0.090s][info][methodhandles]  - this oop:          0x00000001303d6238
[0.090s][info][methodhandles]  - method holder:     public synchronized abstract 'java/lang/invoke/MethodHandle'
(Omitted)
[0.090s][info][methodhandles]  - signature handler: 0x0000000000000000
[0.090s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
[0.090s][info][methodhandles]  - this oop:          0x00000001303d6238

Target log messages are from `{method}` to `- signature handler`.


$ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
(Omitted)
[0.134s][info][methodhandles] lookup_polymorphic_method linkToStatic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; => basic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
[0.134s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
[0.134s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
[0.134s][info][methodhandles]  - this oop:          0x000000012abd5e58

When those flags are off, UL doesn't output them. 

# Test
There is no test code for it. So I built and run OpenJDK to confirm log output by myself.

## Run with Log Level DEBUG After Applying This Patch

$ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=debug -version
(Omitted)
[0.132s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
[0.132s][debug][methodhandles] {method}
[0.132s][debug][methodhandles]  - this oop:          0x00000001217d6b98
(Omitted)
[0.132s][debug][methodhandles]  - signature handler: 0x0000000000000000
[0.132s][info ][methodhandles] lookup_polymorphic_method => intrinsic {method}
[0.132s][info ][methodhandles]  - this oop:          0x00000001217d6b98

UL outputted target log messages with the debug level. It was successful.

## Run with Log Level INFO After Applying This Patch

$ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
(Omitted)
[0.086s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
[0.086s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
[0.086s][info][methodhandles]  - this oop:          0x000000011f7d69f8

UL didn't output them. That was as I intended.

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

Commit messages:
 - Change the log level
 - Change the log level

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

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

From iklam at openjdk.java.net  Thu Jun 16 03:30:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 16 Jun 2022 03:30:49 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
Message-ID: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>

HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.

iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.

This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

Commit messages:
 - fixed Shenandoah build
 - 8288537: Refactor hotspot/share/memory/iterator.hpp

Changes: https://git.openjdk.org/jdk/pull/9176/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288537
  Stats: 568 lines in 28 files changed: 337 ins; 214 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From jwilhelm at openjdk.java.net  Thu Jun 16 07:09:00 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 07:09:00 GMT
Subject: RFR: Merge jdk19
Message-ID: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8288533: Missing @param tags in com.sun.source classes
 - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64
 - 8288414: Long::compress/expand samples are not correct
 - 8288289: Preview APIs in jdk.jdi, jdk.management, and jdk.jfr should be reflective preview APIs
 - 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
 - 8288360: CI: ciInstanceKlass::implementor() is not consistent for well-known classes
 - 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read
 - 8288303: C1: Miscompilation due to broken Class.getModifiers intrinsic
 - 8288214: serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java test failed
 - ... and 1 more: https://git.openjdk.org/jdk/compare/39526e28...8b43a607

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9179/files
  Stats: 254 lines in 17 files changed: 193 ins; 13 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/9179.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9179/head:pull/9179

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

From stefank at openjdk.java.net  Thu Jun 16 08:15:08 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 16 Jun 2022 08:15:08 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

Even though the name sounds generic, the Devirtualizer class was written to support the oop_iterate / OopIterateClosure devirtualization. (Maybe a hint that this should be renamed)

This patch splits the implementation of this devirtualization into two different files. I think that's unfortunate. I'd rather see that we kept that code together. Maybe move all the code into a new oopIterateClosure.inline.hpp file.

However, if you do so, you'll find that we would almost move all the code out of iterator.inline.hpp. To me that makes it unclear how much the move of the Devirtualizer contributed to the fixed compilation time.

Since this patch moves two completely separate closures, could you repurpose this PR to only move the SerializeClosure, so that we can evaluate the move of the OopIterateClosure separately?

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

Changes requested by stefank (Reviewer).

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

From jwilhelm at openjdk.org  Thu Jun 16 12:05:20 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 12:05:20 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
References: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
Message-ID: <jE5ZH0NidXVkm_bPpXtl0UPI_FXUl9NK5fQyfDq6Cvg=.57654ad5-3d0b-4019-a178-2777c19d9611@github.com>

On Thu, 16 Jun 2022 07:00:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 3d12c022
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d12c0225b31bb359bec70aac6befd879cd0c934
Stats:     254 lines in 17 files changed: 193 ins; 13 del; 48 mod

Merge

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

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

From dchuyko at openjdk.org  Thu Jun 16 12:30:38 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Jun 2022 12:30:38 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v5]
In-Reply-To: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
Message-ID: <m0RH-Vnofdk04xYZ5PMleykSBE2d9Lap4E6MMQlqGcs=.f33ef043-e1ee-4ba7-b086-2e7cff8f2339@github.com>

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

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

  Moved 2 prfm-s from wrong ifdef branch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8779/files
  - new: https://git.openjdk.org/jdk/pull/8779/files/89aa16ff..653ebf42

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

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

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

From dchuyko at openjdk.org  Thu Jun 16 12:35:39 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Jun 2022 12:35:39 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v6]
In-Reply-To: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
Message-ID: <q2qM3ZXyB_fu-POr5jeGYiHnqV_xHh015mGgIBxvAqM=.601431ee-3e5e-482f-97f1-a7d5de9da08d@github.com>

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

Dmitry Chuyko 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:

 - Merge branch 'openjdk:master' into JDK-8282322
 - Moved 2 prfm-s from wrong ifdef branch
 - Removed unnecessary changes (forced UseLSE, blank lines)
 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
 - Revert "hardlse feature"
   
   This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
 - Merge branch 'openjdk:master' into JDK-8282322
 - hardlse feature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8779/files
  - new: https://git.openjdk.org/jdk/pull/8779/files/653ebf42..018172ca

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

  Stats: 20839 lines in 509 files changed: 15267 ins; 3554 del; 2018 mod
  Patch: https://git.openjdk.org/jdk/pull/8779.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8779/head:pull/8779

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

From coleenp at openjdk.org  Thu Jun 16 12:41:35 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jun 2022 12:41:35 GMT
Subject: RFR: 8288064: Class initialization locking [v3]
In-Reply-To: <SjD4fnGENdPyyIh6lQIXhz2SCr-GKS_i9EIqIEgVdk4=.598aece6-0792-4b54-bee8-01fc33beb470@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
 <SjD4fnGENdPyyIh6lQIXhz2SCr-GKS_i9EIqIEgVdk4=.598aece6-0792-4b54-bee8-01fc33beb470@github.com>
Message-ID: <wAMYztsHE8VYRsabh40JZXLMtf2f319EP7ozHKQAwB4=.50488daf-6755-4643-84d3-ad388226fe5a@github.com>

On Wed, 15 Jun 2022 13:44:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
>> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed is_reentrant again and added an assert.

Tests in tier1-4 pass with this new assert, which we expected. @dholmes-ora told me offline these were drive-by comments and I've made the suggested changes.  Thanks David.

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

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

From coleenp at openjdk.org  Thu Jun 16 12:41:37 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jun 2022 12:41:37 GMT
Subject: Integrated: 8288064: Class initialization locking
In-Reply-To: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
References: <4T7cYiyk2HtOzwK1XVIKcVsSBKiOpQac1eISSJtJImE=.8a9ade89-3048-463d-b8e0-599a61c31e78@github.com>
Message-ID: <5BWOwJVpemV6bpDpva3o_FEfqBfzQdks9CpEsCI8Djo=.b32ca5df-d12b-4b64-9ee0-f06b58b2e364@github.com>

On Mon, 13 Jun 2022 17:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Use a native JVM monitor and state for mutual exclusion for class linking and initialization.  See CR for more details.
> Tested with tier1-8. tiers 1-4 on Oracle supported platforms and 5-8 on linux-x64-debug.  There isn't any platform dependent code in this change.

This pull request has now been integrated.

Changeset: cf4a4966
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf4a4966a846ebea7e07c4ee6387fbf1081ea385
Stats:     261 lines in 14 files changed: 89 ins; 121 del; 51 mod

8288064: Class initialization locking

Reviewed-by: rehn, vlivanov

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

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

From dchuyko at openjdk.org  Thu Jun 16 12:47:23 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Jun 2022 12:47:23 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v4]
In-Reply-To: <1b4wdroArKPV_H9rNh7xSScwl1_mYObW8ab4dk5UXjI=.cd449315-f98e-4525-bebe-6755f392bab6@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
 <MgiLWpU-xTP-PTuA12LKRao4A5bzOwkyIlebzAaRdDU=.2d58a12c-9529-4e00-a582-8811c052e787@github.com>
 <1b4wdroArKPV_H9rNh7xSScwl1_mYObW8ab4dk5UXjI=.cd449315-f98e-4525-bebe-6755f392bab6@github.com>
Message-ID: <MAX3ePNWhepknqtyEETok0VCFcETzwD7x_AB2dX23QE=.e327ba67-166e-4a8f-8518-6c850ee37b38@github.com>

On Thu, 9 Jun 2022 08:56:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dmitry Chuyko 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:
>> 
>>  - Removed unnecessary changes (forced UseLSE, blank lines)
>>  - Merge branch 'openjdk:master' into JDK-8282322
>>  - Merge branch 'openjdk:master' into JDK-8282322
>>  - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
>>  - Revert "hardlse feature"
>>    
>>    This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
>>  - Merge branch 'openjdk:master' into JDK-8282322
>>  - hardlse feature
>
> src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 266:
> 
>> 264: aarch64_atomic_cmpxchg_4_relaxed_default_impl:
>> 265: #ifdef __ARM_FEATURE_ATOMICS
>> 266:         prfm    pstl1strm, [x0]
> 
> This still looks wrong. You do want PRFM before LDXR, surely. Not before CAS.

Thanks, fixed both points to be similar to others.

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

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

From dchuyko at openjdk.org  Thu Jun 16 12:58:29 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 16 Jun 2022 12:58:29 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v7]
In-Reply-To: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
Message-ID: <bJJWEC0pl4wg_pjWyUzRRHfwarpEGz_8_acYNpBGCy8=.67799a05-46c6-457c-b7c9-d04c3f6e274e@github.com>

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

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

 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Moved 2 prfm-s from wrong ifdef branch
 - Removed unnecessary changes (forced UseLSE, blank lines)
 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
 - Revert "hardlse feature"
   
   This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
 - Merge branch 'openjdk:master' into JDK-8282322
 - hardlse feature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8779/files
  - new: https://git.openjdk.org/jdk/pull/8779/files/018172ca..9e5a1ee9

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

  Stats: 261 lines in 14 files changed: 89 ins; 121 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/8779.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8779/head:pull/8779

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

From iklam at openjdk.org  Thu Jun 16 15:28:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Jun 2022 15:28:47 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>
Message-ID: <ngCven4rd6ujy-8nIfzu1iHIMkAjhqyNLKXGjOoOGOg=.351af1e1-61a6-4cc9-894b-fec29865c9fb@github.com>

On Thu, 16 Jun 2022 08:11:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Even though the name sounds generic, the Devirtualizer class was written to support the oop_iterate / OopIterateClosure devirtualization. (Maybe a hint that this should be renamed)
> 
> This patch splits the implementation of this devirtualization into two different files. I think that's unfortunate. I'd rather see that we kept that code together. Maybe move all the code into a new oopIterateClosure.inline.hpp file.
> 
> However, if you do so, you'll find that we would almost move all the code out of iterator.inline.hpp. To me that makes it unclear how much the move of the Devirtualizer contributed to the fixed compilation time.
> 
> Since this patch moves two completely separate closures, could you repurpose this PR to only move the SerializeClosure, so that we can evaluate the move of the OopIterateClosure separately?

The main problem is:

- Devirtualizer inline functions are simpler, but they are needed by many object files
- OopIterateClosure inline functions are complex (and have lots of dependencies, due to the expansion of `OopOopIterateDispatch::Table::Table()`), but they are needed by very few object files

Here's the output of https://urldefense.com/v3/__https://github.com/iklam/tools/blob/main/headers/whoincludes.tcl__;!!ACWV5N9M2RV99hQ!M1d4EE1kt0yOwJR6nh1Bl1ZK-kCquJrtBmNWfKFPLb1oq97HUvKXfFj21YYJXI_J1_svLgmRq547cmhb35gK$ :

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

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

From iklam at openjdk.org  Thu Jun 16 20:02:24 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Jun 2022 20:02:24 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
Message-ID: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>

javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.

The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.

- jdk_internal_vm_ContinuationScope
- jdk_internal_vm_Continuation
- jdk_internal_vm_StackChunk

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

Commit messages:
 - 8288623: Move Continuation classes out of javaClasses.hpp

Changes: https://git.openjdk.org/jdk/pull/9191/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288623
  Stats: 1032 lines in 9 files changed: 580 ins; 441 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

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

From iklam at openjdk.org  Thu Jun 16 22:23:51 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Jun 2022 22:23:51 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

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

  added missing includes that were hidden by previously unnedded includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/001c2156..caf085a4

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

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

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

From stefank at openjdk.org  Fri Jun 17 08:40:51 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 08:40:51 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
Message-ID: <yLHYSPYU9YHMTfnWLYIX66sFwBHFi8IXtUztYECREuw=.8945fb97-363b-4e93-8863-ae1f89313c07@github.com>

On Thu, 16 Jun 2022 22:23:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing includes that were hidden by previously unnedded includes

If we are about to start to squirrel away parts of javaClasses into new files, I wonder if the discoverability of these functions will be better if we use this naming instead:

javaClasses.hpp
javaClassesContinuation.hpp
javaClassesInvoke.hpp
...

instead of:

javaClasses.hpp
continuationJavaClasses.hpp
invokeJavaClasses.hpp
...

src/hotspot/share/classfile/continuationJavaClasses.inline.hpp line 26:

> 24: 
> 25: #ifndef SHARE_CLASSFILE_JDK_INTERNAL_VM_STACKCHUNK_INLINE_HPP
> 26: #define SHARE_CLASSFILE_JDK_INTERNAL_VM_STACKCHUNK_INLINE_HPP

This include guard doesn't follow the current naming convention.

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

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

From stefank at openjdk.org  Fri Jun 17 08:59:50 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 08:59:50 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

I forgot that Loom hijacked Devirtualizer for the derived oops processing. This devirtualization is not needed. The compiler sees the correct type and performs the correct inlining anyway. Before the integration of Loom I removed the usage of Devirtualizer::do_bit and verified that the compiler generated the same code (though I forgot to remove function).

I took and tested removing Devirtualizer::do_derived_oops, and again, the compiler generated the same code. So, simplest would be to just remove that function and the include of iterator.inline.hpp. However, if you still want to do this separation, then I guess that's OK as well. Could you move the Devirtualizer class to utilities/ instead of oops/, given that it's not necessarily oops that we are visiting? Maybe also update the comment to not mention OopClosureType.

Sounds good to move the OopIterateDispatch code to oops/oopIterateDispatch.

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

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

From aph at openjdk.org  Fri Jun 17 09:28:14 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 17 Jun 2022 09:28:14 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <B8WuOWl_39ppfyZuz8fAoCmlwSPvDzLFF1ikhF-N0S8=.fd498ddb-7854-4616-802c-a0675dbb031c@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <t1Gigc1XLRETSXriG2Bw9-zZGbaJxxIj-Hda3sRBGf8=.60774236-39cc-4f39-b757-076d33af675b@github.com>
 <B8WuOWl_39ppfyZuz8fAoCmlwSPvDzLFF1ikhF-N0S8=.fd498ddb-7854-4616-802c-a0675dbb031c@github.com>
Message-ID: <ONVSGWta7auQsl98toVizl8e6L9USdeZNzwdrg48gmQ=.d71dd705-43cb-43b7-a3f1-a18e40ec103f@github.com>

On Wed, 8 Jun 2022 14:13:01 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> If we never patch the branch to the interpreter, we can optimize it at link time either to a direct branch or an adrp based far jump. I also created https://bugs.openjdk.org/browse/JDK-8286142 to reduce metadata mov instructions.

If we emit the address of the interpreter once, at the start of the stub section, we can replace the branch to the interpreter with
`ldr rscratch1, adr; br rscratch1`.

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

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

From jwilhelm at openjdk.org  Fri Jun 17 12:24:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 17 Jun 2022 12:24:19 GMT
Subject: RFR: Merge jdk19
Message-ID: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8286176: Add JNI_VERSION_19 to jni.h and JNI spec
 - 8287401: jpackage tests failing on Windows due to powershell issue
 - 8288534: Out of bound errors for memory segment access mentions wrong values

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/9197/files
  Stats: 50 lines in 14 files changed: 25 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/9197.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9197/head:pull/9197

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

From jwilhelm at openjdk.org  Fri Jun 17 13:50:58 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Fri, 17 Jun 2022 13:50:58 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>
References: <iAAt-vOyoM8VX3hFOWbmy1AVrFxNuBLzw1dRbe6E4IY=.96c7e0d9-668c-459f-be99-570db613cfa9@github.com>
Message-ID: <x6UTZXwCO29ezzLkLFigvnD4BaqyXY-69f8ivIwKPcc=.e384ca8e-0fe4-431e-a0c5-8384907fff3a@github.com>

On Fri, 17 Jun 2022 12:16:32 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: af64d316
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af64d316c0f687c4ceab7591e050449c64e3babc
Stats:     50 lines in 14 files changed: 25 ins; 3 del; 22 mod

Merge

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

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

From coleenp at openjdk.org  Fri Jun 17 14:38:01 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jun 2022 14:38:01 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
Message-ID: <lOq_BEXN0OjZiHx2gSdSRsIImkmt-vsDy5h2U4mIAN8=.55605b30-df12-4c7a-a247-f3cb741b02f8@github.com>

On Thu, 16 Jun 2022 22:23:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing includes that were hidden by previously unnedded includes

The naming of this follows what jvmci did - they have jvmciJavaClasses.hpp/cpp.  Discovering continuation* is also something useful.

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

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

From iklam at openjdk.org  Fri Jun 17 15:05:05 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:05:05 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp [v2]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <8VmvMkmeRKrAzYr6f7dIOE4GFBzu6tmsOFG33LnIPOM=.92915b50-5906-40e7-aaf0-1fbb18ae70bb@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - moved memory/devirtualizer.hpp -> utilities/devirtualizer.hpp
 - separate out the changes related to SerializeClosure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ebb83152..159e9530

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

  Stats: 208 lines in 26 files changed: 75 ins; 126 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From iklam at openjdk.org  Fri Jun 17 15:13:57 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:13:57 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

  renamed include guard macro

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/159e9530..ba07ef2c

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

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

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

From iklam at openjdk.org  Fri Jun 17 15:13:58 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:13:58 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp
In-Reply-To: <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>
Message-ID: <edSca0RNQSfJxsa8OUi4vbCBKtcprD07zatmi6b1nTg=.85c16128-3e65-4ddd-a374-4064c1e61c65@github.com>

On Fri, 17 Jun 2022 08:55:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I forgot that Loom hijacked Devirtualizer for the derived oops processing. This devirtualization is not needed. The compiler sees the correct type and performs the correct inlining anyway. Before the integration of Loom I removed the usage of Devirtualizer::do_bit and verified that the compiler generated the same code (though I forgot to remove function).
> 
> I took and tested removing Devirtualizer::do_derived_oops, and again, the compiler generated the same code. So, simplest would be to just remove that function and the include of iterator.inline.hpp. However, if you still want to do this separation, then I guess that's OK as well. Could you move the Devirtualizer class to utilities/ instead of oops/, given that it's not necessarily oops that we are visiting? Maybe also update the comment to not mention OopClosureType.
> 
> Sounds good to move the OopIterateDispatch code to oops/oopIterateDispatch.

I think it's still useful to move Devirtualizer out in case it might be used in the future by other code. I've backed out the changes related to SerializeClosure, and moved the header to utilities/devirtualizer.hpp.

If you want to do the Loom cleanup, I'll leave it up to you :-)

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

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

From iklam at openjdk.org  Fri Jun 17 15:21:07 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:21:07 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

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

  fixed include guard macro and copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/caf085a4..ebc3f9f8

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

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

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

From iklam at openjdk.org  Fri Jun 17 15:27:02 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:27:02 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <yLHYSPYU9YHMTfnWLYIX66sFwBHFi8IXtUztYECREuw=.8945fb97-363b-4e93-8863-ae1f89313c07@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
 <yLHYSPYU9YHMTfnWLYIX66sFwBHFi8IXtUztYECREuw=.8945fb97-363b-4e93-8863-ae1f89313c07@github.com>
Message-ID: <5wEyHM_c1xWNi1GCDgXa4u5n9kMza_Pste-20lnhizs=.8de600ac-8f8c-417d-8d7b-e65c577d2325@github.com>

On Fri, 17 Jun 2022 08:37:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> If we are about to start to squirrel away parts of javaClasses into new files, I wonder if the discoverability of these functions will be better if we use this naming instead:
> 
> ```
> javaClasses.hpp
> javaClassesContinuation.hpp
> javaClassesInvoke.hpp
> ...
> ```
> 
> instead of:
> 
> ```
> javaClasses.hpp
> continuationJavaClasses.hpp
> invokeJavaClasses.hpp
> ...
> ```

I am not in love with either naming convention (the names are too long), but the latter sounds more grammatically correct. Also, as Coleen mentioned, if we choose the former, we need to rename jvmciJavaClasses.hpp as well.

The former can be discovered as `javaClasses*` and the latter as `*avaClasses*`, so there's not much difference.

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

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

From mcimadamore at openjdk.org  Fri Jun 17 18:19:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:19:22 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!MiK03dJMoSbrnTTRNsiQZsh6jp-BmXpYoz232Kmxtf7PDrhU2esUdkg4rPyT1zGNi3kENF5MtugCwK4IsPmxvispemmk$ 

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

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

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=01
  Stats: 543 lines in 28 files changed: 48 ins; 110 del; 385 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:24 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:24 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <5qDmnUurtGSqPny2rf0qUp3wafWfpRRvpMJyI_r0VkM=.20cd2a71-bed0-4ef7-80ca-fd6e9efc2528@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!IspNBEPLR399JHXOtcpUbXtutZ6TWwGel_CvWaW52i83IduANhR3C6XaET_sP_0lHQT0aJyubibUyxSIA2l3QkSPn66l$ 

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

  Unify heap vs. implicit scopes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/be81918f..b605aeab

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

  Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
Message-ID: <cCTCVBbOOKw_cFTiqNt4rYCnWYWAGKo5S3kiapdTGxI=.663dbdb4-b47c-4b00-909d-156ea8b42ecf@github.com>

On Fri, 17 Jun 2022 18:19:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!NKaLRXGUrjV74Qw0pdOS2gEFmE41gxR1t5AsuEXtpjGNMkjHpfin5bftb3KvvZp3x4v70PQ00w64KXkkB4HaQTYENqrk$ 
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix issue in Direct-X-Buffer template
>  - Simplify and drop the state class
>  - Add missing files
>  - Initial push

I ended up simplifying this PR, by selecting some of the improvement from the previous patch:
* simplify handling of "readOnly" for memory segments
* Remove duplication between `sessionImpl` and `session` accessors, by making non-closeable views also be subclasses of `MemorySessionImpl`
* use better naming for the `checkValidState` methods - now the plain method is the method that should be used by all clients, while `checkValidStateRaw` is the method that should only be used in ScopedMemoryAccess
* unify exception handling, and fix issues around WrongThreadException not being handled correctly in ScopedMemoryAccess

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:39:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:39:03 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!K03iWFwG2GCP5MJN9A_Hd4-JjpUD8BKrnB82ccbv2QsiBE8xKLh75VM34GWzKIG668bVcI7FYIyoIGWTozH9DqWXZv_M$ 

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

  Revert implicit vs. heap session changes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/b605aeab..a6841b24

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

  Stats: 14 lines in 5 files changed: 4 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From dchuyko at openjdk.org  Fri Jun 17 20:06:55 2022
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Fri, 17 Jun 2022 20:06:55 GMT
Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX
 family of instructions [v8]
In-Reply-To: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
References: <QMuVxlErfLMPOOZv5jziA2SfGB6sfqu675ff1vOeJcY=.54eb0f80-8a9a-46fa-b118-4a9fb02d1201@github.com>
Message-ID: <fD35F3uzZO8NxJRXq4fg9tV6dtsleKHxjgirOE_Wutw=.a1466327-3186-4ce5-9a9f-db8721361080@github.com>

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

Dmitry Chuyko 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 11 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Moved 2 prfm-s from wrong ifdef branch
 - Removed unnecessary changes (forced UseLSE, blank lines)
 - Merge branch 'openjdk:master' into JDK-8282322
 - Merge branch 'openjdk:master' into JDK-8282322
 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on
 - Revert "hardlse feature"
   
   This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5.
 - Merge branch 'openjdk:master' into JDK-8282322
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ec80ff91...d1ae97d9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8779/files
  - new: https://git.openjdk.org/jdk/pull/8779/files/9e5a1ee9..d1ae97d9

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

  Stats: 882 lines in 40 files changed: 214 ins; 465 del; 203 mod
  Patch: https://git.openjdk.org/jdk/pull/8779.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8779/head:pull/8779

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

From stefank at openjdk.org  Fri Jun 17 20:18:01 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 20:18:01 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
Message-ID: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>

On Fri, 17 Jun 2022 15:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed include guard macro

Sounds good to me :)

src/hotspot/share/utilities/devirtualizer.inline.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

Since these new files are mainly copied code, would you mind retaining the copyright dates. Right now this look like newly created code.

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

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

From stefank at openjdk.org  Fri Jun 17 20:18:02 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 20:18:02 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
Message-ID: <MQcP-g5eXuHgt2xVOiu52_5MduS5_kVvFvMbNGxJBWA=.3ec153f7-112a-4667-b257-870d93bc3d1f@github.com>

On Fri, 17 Jun 2022 15:21:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed include guard macro and copyright year

src/hotspot/share/classfile/continuationJavaClasses.cpp line 28:

> 26: #include "classfile/javaClassesImpl.hpp"
> 27: #include "classfile/javaClasses.hpp"
> 28: #include "classfile/continuationJavaClasses.hpp"

Include order

src/hotspot/share/classfile/javaClassesImpl.hpp line 26:

> 24: 
> 25: #ifndef SHARE_CLASSFILE_JAVACLASSES_IMPL_HPP
> 26: #define SHARE_CLASSFILE_JAVACLASSES_IMPL_HPP

Convention is to name this:
SHARE_CLASSFILE_JAVACLASSESIMPL_HPP

src/hotspot/share/classfile/javaClassesImpl.hpp line 29:

> 27: 
> 28: #include "classfile/javaClasses.hpp"
> 29: #include "classfile/continuationJavaClasses.hpp"

Include order

src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 31:

> 29: 
> 30: #include "oops/stackChunkOop.hpp"
> 31: #include "gc/g1/g1BarrierSet.hpp"

Include order

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

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

From stefank at openjdk.org  Fri Jun 17 20:22:55 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 20:22:55 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
Message-ID: <DKTBMylz4j__VRfHkVdU_6VN1AagkOUovnRHa7_xBL0=.69ce82e8-5c82-4417-b6dd-dc7c0187b773@github.com>

On Fri, 17 Jun 2022 15:21:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed include guard macro and copyright year

I've talked to Ioi and Coleen about whether `javaClasses` or `continuations` should be the considered the most relevant subsystem. Their take is that `continuations` is. I'm warming up to that thought, but I think I'd then would prefer if continuationsJavaClasses.hpp etc. get moved to where the other continuation files are, in the runtime/ directory.

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

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

From duke at openjdk.org  Fri Jun 17 20:31:54 2022
From: duke at openjdk.org (kristylee88)
Date: Fri, 17 Jun 2022 20:31:54 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
Message-ID: <eUIkPFv4bC8gJzd4f3y8ONn4IjLXW82BGMzG43PJ_zM=.39c94239-c22c-4146-bd64-2341779e853d@github.com>

On Fri, 17 Jun 2022 15:21:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed include guard macro and copyright year

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

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

From mcimadamore at openjdk.org  Fri Jun 17 20:42:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 20:42:59 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!PyJTBQFfrvgixzVupGwOUq-V5WVQBT5AK-f2bJE65yK6tQLlqTJ7674dXZXKCgOdi10B8FbgxpD1zU1rEM0-vZy8RTMn$ 
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:

> 528:             bufferSession = bufferSegment.session;
> 529:         } else {
> 530:             bufferSession = MemorySessionImpl.heapSession(bb);

I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

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

PR: https://git.openjdk.org/jdk19/pull/22

From coleenp at openjdk.org  Fri Jun 17 20:53:53 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jun 2022 20:53:53 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
Message-ID: <e_1KhnRerWPFNH_xXcGxLzoMi5L4TakYlgH2cZf92Ts=.2bfb6a1a-6616-4a31-8f06-f6ef47a7f9f9@github.com>

On Fri, 17 Jun 2022 15:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed include guard macro

Looks like an improvement.

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

Marked as reviewed by coleenp (Reviewer).

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

From mcimadamore at openjdk.org  Fri Jun 17 21:50:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:50:05 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
Message-ID: <cw0qgrS7-SFUAkNN-b0fUDZRZJaqTUO8YTAeqohDimk=.1e6ee1ad-4499-4578-b2c8-4087b68fdaae@github.com>

On Fri, 17 Jun 2022 20:39:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:
> 
>> 528:             bufferSession = bufferSegment.session;
>> 529:         } else {
>> 530:             bufferSession = MemorySessionImpl.heapSession(bb);
> 
> I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

I've filed a dependent PR for this: https://urldefense.com/v3/__https://github.com/openjdk/jdk19/pull/39__;!!ACWV5N9M2RV99hQ!IRFxYyveK5FVpoX5zFFOYyd0av8_QMF4vo17GJNXjvjnqzZpJi5sFfyVgL-ZjDUPOnQNHFUkbdlbcLBdlSM2QHJugy2z$ 

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

PR: https://git.openjdk.org/jdk19/pull/22

From sspitsyn at openjdk.org  Sat Jun 18 01:52:37 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Jun 2022 01:52:37 GMT
Subject: RFR: 8286836: Crash in GetSetLocalTest: No support for deferred values
 in continuations
Message-ID: <9rRIoIEFsAnpGZtYoltViZvsbs1SODTBpIL8hHJ3q9U=.4c0e9119-8dff-4a47-9960-df3e22bc83a8@github.com>

The JVMTI `SetLocalXXX` requires the target virtual thread suspended at a breakpoint or single step event.

This is the relevant statement from the `"Local Variable"` section:

  `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.`

This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target virtual thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:

open/src/hotspot/share/runtime/vframe.cpp:300
# assert(stack_chunk() == __null) failed: Not supported for heap frames 


Also, this is an analysis from Ron (please, see it in the bug report comment):

The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.

However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.

If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 


Changes GetSetLocalTest test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.

The fix was tested with thousands of runs of the GetSetLocalTest on Linux, Windows and MacOs.

Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

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

Commit messages:
 - 8286836: Crash in GetSetLocalTest: No support for deferred values in continuations

Changes: https://git.openjdk.org/jdk19/pull/41/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=41&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286836
  Stats: 29 lines in 3 files changed: 18 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk19/pull/41.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/41/head:pull/41

PR: https://git.openjdk.org/jdk19/pull/41

From sspitsyn at openjdk.org  Sat Jun 18 03:02:52 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Jun 2022 03:02:52 GMT
Subject: Withdrawn: 8286836: Crash in GetSetLocalTest: No support for deferred
 values in continuations
In-Reply-To: <9rRIoIEFsAnpGZtYoltViZvsbs1SODTBpIL8hHJ3q9U=.4c0e9119-8dff-4a47-9960-df3e22bc83a8@github.com>
References: <9rRIoIEFsAnpGZtYoltViZvsbs1SODTBpIL8hHJ3q9U=.4c0e9119-8dff-4a47-9960-df3e22bc83a8@github.com>
Message-ID: <FP-gxAepyW-zx2vgwSRheDYmwSPd0KE3nNEH-5XtmQ4=.751b06df-5994-4e39-b818-5fea943e45e0@github.com>

On Sat, 18 Jun 2022 01:43:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI `SetLocalXXX` requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the `"Local Variable"` section:
> 
>   `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.`
> 
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes GetSetLocalTest test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the GetSetLocalTest on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk19/pull/41

From sspitsyn at openjdk.org  Sat Jun 18 04:06:26 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Jun 2022 04:06:26 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with
 assert: Not supported for heap frames
Message-ID: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>

The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.

This is the relevant statement from the "Local Variable" section:

`The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
`
This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:


open/src/hotspot/share/runtime/vframe.cpp:300
# assert(stack_chunk() == __null) failed: Not supported for heap frames 

Also, this is an analysis from Ron:

The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.

However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.

If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 


Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.

The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.

Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

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

Commit messages:
 - 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames

Changes: https://git.openjdk.org/jdk19/pull/42/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=42&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286580
  Stats: 29 lines in 3 files changed: 18 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk19/pull/42.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/42/head:pull/42

PR: https://git.openjdk.org/jdk19/pull/42

From lmesnik at openjdk.org  Sat Jun 18 19:16:52 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Jun 2022 19:16:52 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <sen0QP9ihpqIx2EIX7wVUMZvLnv2H53hNodvhgKDAaM=.c75b6503-16e9-4fd1-b314-0b9ecc236baa@github.com>

On Sat, 18 Jun 2022 03:59:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/42

From dholmes at openjdk.org  Mon Jun 20 00:21:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jun 2022 00:21:47 GMT
Subject: RFR: 8280472: Don't mix legacy logging with UL
In-Reply-To: <CS9Ss9ECb-swrKB4RypFmTsW8TlHz8Pr_zJTFAzk9mc=.fc3f348d-730c-4c34-91b7-651c74802b57@github.com>
References: <CS9Ss9ECb-swrKB4RypFmTsW8TlHz8Pr_zJTFAzk9mc=.fc3f348d-730c-4c34-91b7-651c74802b57@github.com>
Message-ID: <dbBBdL-6DiSmAa1_l-O1GL37Ixo-doK18zgf4g1TqC0=.ae56c772-bc20-42af-8b52-96f48b7eb5b7@github.com>

On Thu, 16 Jun 2022 01:39:33 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This PR remove extra conditions related to Unified Logging.
> 
> Those conditions have been left after the transition to Unified Logging. This is an only place that uses UL, Verbose and WizardMode flags together. This JBS issue suggests to remove those flags.
> 
> # Details
> At present to output target log messages needs the debug build of OpenJDK and, Verbose or WizardMode option.
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -XX:+Verbose -version
> (Omitted)
> [0.090s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.090s][info][methodhandles] {method}
> [0.090s][info][methodhandles]  - this oop:          0x00000001303d6238
> [0.090s][info][methodhandles]  - method holder:     public synchronized abstract 'java/lang/invoke/MethodHandle'
> (Omitted)
> [0.090s][info][methodhandles]  - signature handler: 0x0000000000000000
> [0.090s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.090s][info][methodhandles]  - this oop:          0x00000001303d6238
> 
> Target log messages are from `{method}` to `- signature handler`.
> 
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
> (Omitted)
> [0.134s][info][methodhandles] lookup_polymorphic_method linkToStatic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; => basic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.134s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.134s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.134s][info][methodhandles]  - this oop:          0x000000012abd5e58
> 
> When those flags are off, UL doesn't output them. 
> 
> # Test
> There is no test code for it. So I built and run OpenJDK to confirm log output by myself.
> 
> ## Run with Log Level DEBUG After Applying This Patch
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=debug -version
> (Omitted)
> [0.132s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.132s][debug][methodhandles] {method}
> [0.132s][debug][methodhandles]  - this oop:          0x00000001217d6b98
> (Omitted)
> [0.132s][debug][methodhandles]  - signature handler: 0x0000000000000000
> [0.132s][info ][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.132s][info ][methodhandles]  - this oop:          0x00000001217d6b98
> 
> UL outputted target log messages with the debug level. It was successful.
> 
> ## Run with Log Level INFO After Applying This Patch
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
> (Omitted)
> [0.086s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.086s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.086s][info][methodhandles]  - this oop:          0x000000011f7d69f8
> 
> UL didn't output them. That was as I intended.

The more behaviour-preserving change would be to use log_develop_debug so that this output is only present in develop builds, but as Vladimir made the suggestion to change it I guess it is okay.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From rehn at openjdk.org  Mon Jun 20 06:59:39 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 20 Jun 2022 06:59:39 GMT
Subject: RFR: 8286957: Held monitor count
Message-ID: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>

The current implementation do not count all monitor enter, counts high up in abstraction and causes a performance regression on aarch64 with some benchmarks due to C2 changes.

This change makes the counting exact by pushing the counting down in the abstraction.
The additional JNI counter is strictly not needed, but enables us to figure out if we have monitors "on stack".

An uncontended lock plus unlock is 1 ns (21.5 -> 22.5) slower in C2 compiled code on x64 with the additional increment and decrement.

Fixed aarch64, x64, x86 and zero.

Passes t1-8

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

Commit messages:
 - 8286957 - PR Baseline

Changes: https://git.openjdk.org/jdk/pull/8945/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8945&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286957
  Stats: 516 lines in 42 files changed: 301 ins; 142 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/8945.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8945/head:pull/8945

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

From stuefe at openjdk.org  Mon Jun 20 10:37:11 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 20 Jun 2022 10:37:11 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random
 crashes
Message-ID: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>

After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.

JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.

This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.

So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 

If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.

This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."

A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.

----

Testing:
- GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
- Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch

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

Commit messages:
 - Use real static safefetch on linux arm

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

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

From coleenp at openjdk.org  Mon Jun 20 15:59:16 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 20 Jun 2022 15:59:16 GMT
Subject: RFR: 8288752: Split thread implementation files
Message-ID: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>

This changes splits thread.hpp/cpp into javaThread, and threads files.

I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.

I didn't update the copyrights to save diffs but will before integration.
Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.

Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

Commit messages:
 - Remove more includes, alphatize forward declarations.
 - Make compile on all platforms (including ppc, s390 and zero)
 - rename os_cpu/thread_os_cpu.{hpp,cpp} to os_cpu/javaThread_os_cpu.{hpp,cpp}
 - Separate thread.hpp into thread.hpp, javaThread.hpp and threads.hpp.
 - include thread.hpp not thread.inline.hpp unless inline is needed
 - Builds with javaThread.inline.hpp
 - Split thread.cpp into thread.cpp,javaThread.cpp and threads.cpp files.

Changes: https://git.openjdk.org/jdk/pull/9218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288752
  Stats: 10819 lines in 369 files changed: 5470 ins; 5159 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

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

From shade at openjdk.org  Mon Jun 20 18:07:13 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 20 Jun 2022 18:07:13 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
Message-ID: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>

Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure:


In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35,
                 from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35,
                 from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29,
                 from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28,
                 from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34:
In function 'const void* memchr(const void*, int, size_t)',
    inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32,
    inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19,
    inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41,
    inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6,
    inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19:

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk19/pull/49/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=49&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288759
  Stats: 25 lines in 3 files changed: 19 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/49.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/49/head:pull/49

PR: https://git.openjdk.org/jdk19/pull/49

From jwilhelm at openjdk.org  Mon Jun 20 18:28:50 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 18:28:50 GMT
Subject: RFR: Merge jdk19
Message-ID: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8288527: broken link in java.base/java/util/zip/package-summary.html
 - 8288741: JFR: Change package name of snippet files
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
 - 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
 - 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
 - 8288564: C2: LShiftLNode::Ideal produces wrong result after JDK-8278114
 - 8288397: AArch64: Fix register issues in SVE backend match rules
 - 8288692: jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java fails after JDK-8288545
 - 8268398: 15% increase in JFR footprint in Noop-Base
 - ... and 1 more: https://git.openjdk.org/jdk/compare/302a6c06...6efc7e9e

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9220&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9220/files
  Stats: 752 lines in 36 files changed: 538 ins; 58 del; 156 mod
  Patch: https://git.openjdk.org/jdk/pull/9220.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9220/head:pull/9220

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

From snazarki at openjdk.org  Mon Jun 20 18:54:46 2022
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 20 Jun 2022 18:54:46 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
Message-ID: <pzmFNkTHZxGi2zDKYm8e9ujG67xsLs82hf6TUTpUK4E=.b1ff5c66-c655-4d4f-8709-b7e33c93d1e1@github.com>

On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.
> 
> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.
> 
> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.
> 
> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 
> 
> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.
> 
> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."
> 
> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.
> 
> ----
> 
> Testing:
> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch

Marked as reviewed by snazarki (no project role).

Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb  even with crossbuilds. 
LGTM

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

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

From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <wOC-cOnunQe0dlkf1uVHOn0PrafZajxmhFD_Rg6cwuI=.072a626a-5ae7-4ed5-a0a6-d3eeacd89c8b@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson 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 96 additional commits since the last revision:

 - Merge
 - 8287801: Fix test-bugs related to stress flags
   
   Reviewed-by: chagedorn, thartmann
 - 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
   
   Reviewed-by: jbachorik, egahlin
 - 8287771: Remove useless G1 After GC summary refinement and sampling thread times
   
   Reviewed-by: tschatzl, kbarrett
 - 8288011: StringConcatFactory: Split application of stringifiers
   
   Reviewed-by: jvernee, mchung
 - 8288685: JFR: Use static methods for Active Recording and Active Setting events
   
   Reviewed-by: mgronlun
 - 8288673: Reduce runtime of java.time microbenchmarks
   
   Reviewed-by: jvernee
 - 8288667: Reduce runtime of java.text microbenchmarks
   
   Reviewed-by: jvernee
 - 8284672: Collapse identical catch branches in java.desktop
   
   Reviewed-by: prr, aivanov, serb
 - 8288329: Avoid redundant TreeMap.containsKey call in PolicyParser.read
   
   Reviewed-by: mullan
 - ... and 86 more: https://git.openjdk.org/jdk/compare/cb2201b4...6efc7e9e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9220/files
  - new: https://git.openjdk.org/jdk/pull/9220/files/6efc7e9e..6efc7e9e

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

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

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

From jwilhelm at openjdk.org  Mon Jun 20 19:44:19 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 20 Jun 2022 19:44:19 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
References: <cvtpd9RoksS7fxFHaBb5gLifLOq1ICRq871yeUA3LKg=.b796dace-c0c5-416b-9e70-bed600da4cd8@github.com>
Message-ID: <99J0-7NZyn_B1qAUt-E3RDXhVlOBpw5q0y_7OfkWqNU=.c9779d47-1137-44ca-8b97-bd31716fbc11@github.com>

On Mon, 20 Jun 2022 18:20:21 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 7039c661
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7039c6616ad1b67320f08e7ea4763e8ff4977430
Stats:     752 lines in 36 files changed: 538 ins; 58 del; 156 mod

Merge

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

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

From duke at openjdk.org  Mon Jun 20 23:22:00 2022
From: duke at openjdk.org (Yi-Fan Tsai)
Date: Mon, 20 Jun 2022 23:22:00 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v2]
In-Reply-To: <9C9P4NROYxVuWTJejFnYwQOGPovUstzWACIboIQWTDw=.2977b16b-c175-4774-97af-60071b805f46@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <9C9P4NROYxVuWTJejFnYwQOGPovUstzWACIboIQWTDw=.2977b16b-c175-4774-97af-60071b805f46@github.com>
Message-ID: <p81xSKAcq8ZHiES86zmVSrPLyX4guHNnS6S98iO1I7A=.4557fb1c-615a-4a38-a6f7-3b98d20ff355@github.com>

On Sat, 4 Jun 2022 02:02:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove dead codes
>>   
>>   remove unused argument of NativeJump::check_verified_entry_alignment
>>   remove unused argument of NativeJumip::patch_verified_entry
>>   remove dead codes in SharedRuntime::generate_method_handle_intrinsic_wrapper
>
> src/hotspot/share/ci/ciMethod.cpp line 1146:
> 
>> 1144:     CodeBlob* code = get_Method()->code();
>> 1145:     if (code != NULL && code->is_compiled()) {
>> 1146:       code->as_compiled_method()->log_identity(log);
> 
> Doesn't this change the log output?

Yes, the output of MH intrinsic cases will become like the cases where codes are not set. The removed parts are compiled ID, compiler, and compile level. They are all constants for MH intrinsics, not providing much information.

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

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

From dholmes at openjdk.org  Mon Jun 20 23:59:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jun 2022 23:59:00 GMT
Subject: RFR: 8288752: Split thread implementation files
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>

On Mon, 20 Jun 2022 15:49:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Hi Coleen,

The changes in themselves seem fine to me - I only skimmed things, mainly looking at the new files.  It is a very large refactoring so there will be an impact on backports naturally.

I'm not sure this will save much in terms of build time inclusions (how many files only include thread.hpp now?) but the code structure/management benefits of this are more important anyway. (Though I must confess in a remote terminal using vi I appreciate everything being in one file. :) ).

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From sspitsyn at openjdk.org  Tue Jun 21 03:42:47 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Jun 2022 03:42:47 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <FsiOhOdP02b7axkrHmsTbAiWEkJ7lhE-MZ559FQt9nM=.99bdb33f-0b20-4985-83b6-b720ef889a42@github.com>

On Sat, 18 Jun 2022 03:59:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

Thank you for review, Leonid!

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

PR: https://git.openjdk.org/jdk19/pull/42

From iklam at openjdk.org  Tue Jun 21 05:29:35 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 05:29:35 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v4]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

  Updated copyright year to 2018, where the Devirtualizer class was first added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ba07ef2c..ab986620

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

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

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

From iklam at openjdk.org  Tue Jun 21 05:29:36 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 05:29:36 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
 <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
Message-ID: <HWTNPgl89GOBsGZU8zXVNXEw2Ulr5Kh2W3AJreuWJoc=.e0ec72c2-be62-42b3-ae63-ce4440db3c5c@github.com>

On Fri, 17 Jun 2022 20:14:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed include guard macro
>
> src/hotspot/share/utilities/devirtualizer.inline.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Since these new files are mainly copied code, would you mind retaining the copyright dates. Right now this look like newly created code.

I updated the copyright year to 2018-2022, since the Devirtualizer class was first added in 2018 in [JDK-8204540](https://bugs.openjdk.org/browse/JDK-8204540)

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

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

From iklam at openjdk.org  Tue Jun 21 05:38:09 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 05:38:09 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v4]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <9GG6MVLGtcymy9dRGwGrlhsPQddwhDbCslM3HpsiWO4=.2fa74e06-e6fa-471f-ae88-87aabaebe470@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

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

  @stefank review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/ebc3f9f8..145e44ac

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

  Stats: 14 lines in 4 files changed: 5 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

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

From duke at openjdk.org  Tue Jun 21 05:43:43 2022
From: duke at openjdk.org (Yi-Fan Tsai)
Date: Tue, 21 Jun 2022 05:43:43 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v3]
In-Reply-To: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
Message-ID: <a2rdx_TY7jbQma0mYy1G27g-9cuUEoODiv7m8ZsNI0s=.56cab9dd-6350-45eb-b482-f338d97f920e@github.com>

> 8263377: Store method handle linkers in the 'non-nmethods' heap

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Post dynamic_code_generate event when MH intrinsic generated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8760/files
  - new: https://git.openjdk.org/jdk/pull/8760/files/00c99435..e3e9f979

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

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

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

From stuefe at openjdk.org  Tue Jun 21 08:54:53 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 21 Jun 2022 08:54:53 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <pzmFNkTHZxGi2zDKYm8e9ujG67xsLs82hf6TUTpUK4E=.b1ff5c66-c655-4d4f-8709-b7e33c93d1e1@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
 <pzmFNkTHZxGi2zDKYm8e9ujG67xsLs82hf6TUTpUK4E=.b1ff5c66-c655-4d4f-8709-b7e33c93d1e1@github.com>
Message-ID: <KP2GLZ7kfDujz4fYETSI5sEUOwZDvOULYOK_8OAQFE8=.4090bacc-2865-4c64-a913-0ac46f5fcd9e@github.com>

On Mon, 20 Jun 2022 18:50:26 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb even with crossbuilds. LGTM

Thank you, Sergey!

I tried to reproduce this with -mthumb with a crossbuild, but was not able to pass --with-extra-cflags to a devkit crossbuild. I opened https://bugs.openjdk.org/browse/JDK-8288797 to track that.

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

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

From coleenp at openjdk.org  Tue Jun 21 11:59:38 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 11:59:38 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v4]
In-Reply-To: <9GG6MVLGtcymy9dRGwGrlhsPQddwhDbCslM3HpsiWO4=.2fa74e06-e6fa-471f-ae88-87aabaebe470@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <9GG6MVLGtcymy9dRGwGrlhsPQddwhDbCslM3HpsiWO4=.2fa74e06-e6fa-471f-ae88-87aabaebe470@github.com>
Message-ID: <julf37w7ItJlYFmKgZNjfZnVYo4gi9yq7qO1psqcPys=.5934dc24-f297-414e-bf31-57f5583f3bdc@github.com>

On Tue, 21 Jun 2022 05:38:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @stefank review comments

I like this split very much.  JavaClasses was getting too unwieldy. I'm ambivalent whether continuationJavaClasses.cpp/hpp should go in the runtime directory, so please take Stefan's recommendation and move it there.  Tnanks.

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

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.org  Tue Jun 21 12:22:46 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 12:22:46 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

  Fix Shenandoah build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/32b02a42..ae864661

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

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

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

From stefank at openjdk.org  Tue Jun 21 14:14:56 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jun 2022 14:14:56 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v4]
In-Reply-To: <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>
Message-ID: <DdeP-PxbZY6tuaMO3BPjGMZKmI2o_ob6VidStUJfBcc=.b670d08c-6749-4595-9c0d-36c130753323@github.com>

On Tue, 21 Jun 2022 05:29:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year to 2018, where the Devirtualizer class was first added

Marked as reviewed by stefank (Reviewer).

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

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

From rehn at openjdk.org  Tue Jun 21 14:28:58 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jun 2022 14:28:58 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
Message-ID: <ZFHC8q2TwxYYOPkrUVRnr--g7HQIm9tNssSOytGPBU8=.3f5d8ff9-3ce2-40a5-98b2-f48cccd062a7@github.com>

On Tue, 21 Jun 2022 12:22:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Shenandoah build.

Looks good, thanks.

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

Marked as reviewed by rehn (Reviewer).

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

From coleenp at openjdk.org  Tue Jun 21 15:32:15 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 15:32:15 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

  Fix more GHA builds which are slightly different than what we do internally.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/ae864661..93cff18d

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

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

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

From coleenp at openjdk.org  Tue Jun 21 15:32:17 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 15:32:17 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
Message-ID: <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>

On Tue, 21 Jun 2022 12:22:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Shenandoah build.

Thanks David and Robbin.
Unfortunately, this change will make backporting more difficult if we have backport changes from JDK 20.  I still think it's worth separating the thread files.  As a lowly 'vi' user, it's really helpful for me to see whether a field or function belongs to JavaThread or Thread without scrolling up and down the thread.hpp file.  I am guessing that there might be fields in one that really belongs in the other.  This makes it easier, at least for me, to see.

Thank you for the review, Robbin.

I'm still waiting for GHA to pass as I forgot about shenandoah and some of the other platforms build differently.  Also I'm waiting for @dcubed-ojdk changes to JDK 19 to be integrated and merged into JDK 20 first.

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

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

From iklam at openjdk.org  Tue Jun 21 18:02:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:02:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>
Message-ID: <r3qezyI9XyWyljNJnuut8CJMUNkeqzivDgDg5nLXT0g=.54bc31ed-a7b0-4d96-8bc5-09f6d83b9d0e@github.com>

On Tue, 21 Jun 2022 15:32:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix more GHA builds which are slightly different than what we do internally.

Marked as reviewed by iklam (Reviewer).

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

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

From iklam at openjdk.org  Tue Jun 21 18:10:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:10:43 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>
Message-ID: <4PXKkWivdT-CTDMwNarYDw4XqioG-tr-I9x5PfXS6Jw=.8db3a172-ade0-448d-a703-c9526a3c67da@github.com>

On Mon, 20 Jun 2022 23:56:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Coleen,
> 
> The changes in themselves seem fine to me - I only skimmed things, mainly looking at the new files. It is a very large refactoring so there will be an impact on backports naturally.
> 
> I'm not sure this will save much in terms of build time inclusions (how many files only include thread.hpp now?) but the code structure/management benefits of this are more important anyway. (Though I must confess in a remote terminal using vi I appreciate everything being in one file. :) ).
> 
> Thanks.

Currently, as counted by https://urldefense.com/v3/__https://github.com/iklam/tools/blob/main/headers/whoincludes.tcl__;!!ACWV5N9M2RV99hQ!If0dPS2KEsajzrZ1J4CslvRSYiodeiOpm5tFxC7oVfDjGqFpb7fDqaeXL57NtCrZ5XiMjGUL71IhI1oyg5jT$ , there isn't much improvement in terms of build time:

Before this PR:
- thread.hpp was included 847 times

After this PR
- thread.hpp is included 848 times
- javaThread.hpp is included 843 times

One reason is in handles.hpp, which has implicit conversion from `JavaThread*` to `Thread*`. E.g., when you have:


void blah(TRAPS) {
    Handle h(THREAD, someOop);
   . ..
}


Anyway, I think this PR is a very important step towards faster build time. We can do further refactoring. E.g., avoid including handles.hpp unnecessarily in other .hpp files (and move offenders from .hpp to .inline.hpp, etc).

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

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

From sspitsyn at openjdk.org  Tue Jun 21 18:28:16 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Jun 2022 18:28:16 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

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

  remove _depth == 0 clause from sanity check assert

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/42/files
  - new: https://git.openjdk.org/jdk19/pull/42/files/108e3a46..bd1a901c

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

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

PR: https://git.openjdk.org/jdk19/pull/42

From iklam at openjdk.org  Tue Jun 21 18:31:30 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:31:30 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v5]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <9HZIcFQ4y2BgfrZ0CUotalUSqJ2ZM4eVow8uLf_Ek-o=.93fc074e-2022-497e-8956-50a8a84adf14@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

 - Merge branch 'master' of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!ObMbpGgD-mEQOOkk2H4XEA7Phhq3DYDTJzI3lMHfIAvfKHZD9oL2dIObMufcctGXZaWnAmmUG6U4mq2m0NU_$  into 8288537-refactor-iterator-hpp
 - Updated copyright year to 2018, where the Devirtualizer class was first added
 - renamed include guard macro
 - moved memory/devirtualizer.hpp -> utilities/devirtualizer.hpp
 - separate out the changes related to SerializeClosure
 - fixed Shenandoah build
 - 8288537: Refactor hotspot/share/memory/iterator.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ab986620..c2dce9be

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

  Stats: 4585 lines in 234 files changed: 2654 ins; 1047 del; 884 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From duke at openjdk.org  Tue Jun 21 18:39:32 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Tue, 21 Jun 2022 18:39:32 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
Message-ID: <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>

On Fri, 10 Jun 2022 11:36:58 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> GHA testing is not clean.
> 
> I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.

Vladimir(@vnkozlov),
Have you got testing results?

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

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

From ayang at openjdk.org  Tue Jun 21 18:52:21 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jun 2022 18:52:21 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v7]
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <jHL_Dk5zDc7_IOQniW2fW7fr0fjY4Y-piUmHGgYHKGE=.785a8f15-423f-46ab-9e65-b2aad7874119@github.com>

> Simple rename and some comments update.
> 
> Test: build

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - merge
 - merge
 - review
 - comment
 - Rework reference type initialization
   
   Signed-off-by: Albert Yang <albert.m.yang at oracle.com>
 - Remove REF_ enum for java.lang.ref.Reference
   
   Signed-off-by: Albert Yang <albert.m.yang at oracle.com>
 - review
 - ref-rename

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

Changes: https://git.openjdk.org/jdk/pull/8332/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8332&range=06
  Stats: 119 lines in 14 files changed: 81 ins; 31 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/8332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8332/head:pull/8332

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

From ayang at openjdk.org  Tue Jun 21 19:15:36 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Jun 2022 19:15:36 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v8]
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <awt6uVzk8ZvVkuY9EnXYXCkR1YN_Mybb5IVCT0IMAb8=.102e0c84-5008-4eca-8923-e1f0184ef1a5@github.com>

> Simple rename and some comments update.
> 
> Test: build

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8332/files
  - new: https://git.openjdk.org/jdk/pull/8332/files/3fa67ab2..b1c0369a

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

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

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

From coleenp at openjdk.org  Tue Jun 21 19:19:03 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:19:03 GMT
Subject: RFR: 8288752: Split thread implementation files [v4]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <ARMIGfXJT7qW6ol3zhxFL2rjGwi4FXTv5alY0roFjYg=.ad83ae3d-8fb0-4f7e-b457-3d59e192bf1f@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/93cff18d..d2e93ca4

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

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

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

From duke at openjdk.org  Tue Jun 21 19:22:43 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 21 Jun 2022 19:22:43 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>

> Please review this PR for fixing JDK-8287281.
> 
> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Passes tier1. Running tier2-5.

Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:

  Check only for target == current

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8992/files
  - new: https://git.openjdk.org/jdk/pull/8992/files/f2646e04..cc6736cf

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

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

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

From duke at openjdk.org  Tue Jun 21 19:25:38 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 21 Jun 2022 19:25:38 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <SLLW-rkjWcjaiU9h90mFea8f_kS4Ym3SJER2LN-VqDk=.62d5ca0d-9ed3-4c07-aec3-eafa1a32ff98@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

The scope of the ticket is precisely for the case when `Thread::current() == target` and as such the fix only checks for this particular case now.

@dcubed-ojdk, does this change look good to you?

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

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

From coleenp at openjdk.org  Tue Jun 21 19:38:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:38:31 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/d2e93ca4..b420c9e6

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

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

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

From cjplummer at openjdk.org  Tue Jun 21 19:38:47 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 Jun 2022 19:38:47 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
Message-ID: <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>

On Tue, 21 Jun 2022 18:28:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
>> 
>> This is the relevant statement from the "Local Variable" section:
>> 
>> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
>> `
>> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
>> 
>> 
>> open/src/hotspot/share/runtime/vframe.cpp:300
>> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
>> 
>> Also, this is an analysis from Ron:
>> 
>> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
>> 
>> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
>> 
>> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
>> 
>> 
>> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
>> 
>> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
>> 
>> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove _depth == 0 clause from sanity check assert

src/hotspot/share/prims/jvmtiImpl.cpp line 647:

> 645:   }
> 646:   if (_set) {
> 647:     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT

It would be good to elaborate a bit more on this check. Say something about it being a "safepoint poll on return in the oldest thawed frame", and why that is a problem.

test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java line 103:

> 101:         GetSetLocalTest obj = new GetSetLocalTest();
> 102: 
> 103:         for (int i = 0; i < 1000; i++) {

Does this test still run quickly?

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

PR: https://git.openjdk.org/jdk19/pull/42

From duke at openjdk.org  Tue Jun 21 19:56:38 2022
From: duke at openjdk.org (Cesar Soares)
Date: Tue, 21 Jun 2022 19:56:38 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v4]
In-Reply-To: <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
 <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
Message-ID: <AKP_zuoaCiQi7UyT-JrKA6kyOwR7YOJZVCGVbF0o06I=.0442b54b-b5f9-4d99-90a8-57d420038f59@github.com>

On Tue, 14 Jun 2022 03:56:47 GMT, Cesar Soares <duke at openjdk.org> wrote:

>> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
>> 
>> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
>> 
>> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
>> 
>> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
>> 
>> Thanks in advance,
>> Cesar
>
> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge

Hi again, can someone with access to a PPC64, S360, etc. help with testing this?

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

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

From iklam at openjdk.org  Tue Jun 21 19:56:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 19:56:40 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v5]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <vyxq86PlYrngnE9wAK1BW3eWomMKFeiOSeadYu_vH6M=.15443454-ce6e-4208-8d4f-a92e4fcf6663@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

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

  moved to runtime/continuationJavaClasses.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/145e44ac..9d998d7a

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

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

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

From coleenp at openjdk.org  Tue Jun 21 19:58:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:58:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
Message-ID: <GFQBmwY-urzhbLjiC7baSI06s3ZWxr6Rpin1_i61aMo=.9b5917d9-2f4a-48fd-8984-69cbd99c42ba@github.com>

On Tue, 21 Jun 2022 19:38:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

Thanks for reviewing, Ioi.  My intention was more modularity but it's disappointing that the build times don't improve since I culled several (too many, it seems) header files from thread.hpp. But as you said, this is a good step towards the goal of having less excess header file inclusions.

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

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

From coleenp at openjdk.org  Tue Jun 21 20:14:30 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 20:14:30 GMT
Subject: RFR: 8288752: Split thread implementation files [v6]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <QZ1Ymc69ofe-3C2mXXBJOQ783flbp4akYUjipC43Keg=.26bada92-3ece-424a-a469-4fd627721657@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/b420c9e6..5533cd46

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

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

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

From coleenp at openjdk.org  Tue Jun 21 20:17:29 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 20:17:29 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
Message-ID: <WyiJ8WUM3zpBYHvYCNHKQh2bMuJcCx71OFFT8dbQVdA=.e548dfee-cbe3-4c4c-a845-aa6db9ac053d@github.com>

On Tue, 21 Jun 2022 19:38:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

I took out #include "mutexLocker.hpp" from thread.hpp, so on the minimal variant, this isn't transitively included from some other file.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From iklam at openjdk.org  Tue Jun 21 20:58:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 20:58:43 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
 <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
Message-ID: <Ok0PdFL1pf5hatIZHVeedueJTsC8uDKaafW7U8GNe5I=.4c57b2d6-6c24-462d-be9a-f9585ff8c30e@github.com>

On Fri, 17 Jun 2022 20:13:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed include guard macro
>
> Sounds good to me :)

Thanks @stefank @coleenp for the review.
Passes tier-1 and builds-tier5 in our CI. GHA seems to work, too.

-------------

PR: https://git.openjdk.org/jdk/pull/9176

From iklam at openjdk.org  Tue Jun 21 20:58:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 20:58:45 GMT
Subject: Integrated: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <pd6owsItlo-Oy21zbiJh1S88k_NoqpM8LoK9SZb5sSQ=.af6e8606-5cbd-49f8-aa2c-b3cf59141e6e@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

This pull request has now been integrated.

Changeset: 9f8bfab2
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f8bfab29009299e81f4929b5dbd399c21f34d7c
Stats:     387 lines in 15 files changed: 227 ins; 154 del; 6 mod

8288537: Move Devirtualizer out of hotspot/share/memory/iterator.hpp

Reviewed-by: stefank, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/9176

From dcubed at openjdk.org  Tue Jun 21 21:13:23 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 21:13:23 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
 <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>
Message-ID: <UaIUC76MZLzMz47W2QLeY7pKPn4l13pWDWJhoQtZqMk=.99a129d7-4d8c-419f-940e-96a2c3f2ce92@github.com>

On Tue, 21 Jun 2022 15:25:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Also I'm waiting for @dcubed-ojdk changes to JDK 19 to be integrated and merged into JDK 20 first.

My three fixes have been integrated into JDK19. They have not yet been sync'ed
to JDK20. Thank you very much for waiting.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From dcubed at openjdk.org  Tue Jun 21 21:35:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 21:35:18 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <i95gCFql6qW16IgcYV1xXvaygb2W_6fl_bsS-KvC8yo=.89985144-cae9-44b3-992a-16a7caf39ac6@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

Thumbs up. Please see my query about the latest testing.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8992

From dcubed at openjdk.org  Tue Jun 21 21:35:20 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 21:35:20 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <SLLW-rkjWcjaiU9h90mFea8f_kS4Ym3SJER2LN-VqDk=.62d5ca0d-9ed3-4c07-aec3-eafa1a32ff98@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
 <SLLW-rkjWcjaiU9h90mFea8f_kS4Ym3SJER2LN-VqDk=.62d5ca0d-9ed3-4c07-aec3-eafa1a32ff98@github.com>
Message-ID: <mCN_iz96x8FwCtO7h32ILlLYfNppeBala8E0IPU6yNw=.979c8da3-2578-49d6-a5c6-64548ff5de62@github.com>

On Tue, 21 Jun 2022 19:22:55 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check only for target == current
>
> The scope of the ticket is precisely for the case when `Thread::current() == target` and as such the fix only checks for this particular case now.
> 
> @dcubed-ojdk, does this change look good to you?

@jdksjolen - I've reread all the comments in the PR and the latest version of the code
and I'm okay with the latest version. Please clarify what testing has been done on this
latest version of the fix.

-------------

PR: https://git.openjdk.org/jdk/pull/8992

From dcubed at openjdk.org  Tue Jun 21 21:41:00 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 21:41:00 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <pULUVJ8yykRnwzdJRrA4CQk9aHrVRqC8NeEaMDxpwdM=.1b0fce0d-97b2-4cad-8fc5-e56812b93475@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

Just to be clear:

@dholmes-ora wrote this:

Maybe we actually need to backtrack and restore an invariant that there is always a TLH even for the current thread and fix the JVMTI code that did things differently?


@sspitsyn wrote this:

This will make JVMTI code unnecessarily ugly in a couple of spots.
But I'm okay with that if keeping this invariant is important.
I can help with fixing JVMTI if needed.


The current version of the fix does NOT restore the invariant that there is always a TLH
even for the current thread. I'm (mostly) okay with this.

-------------

PR: https://git.openjdk.org/jdk/pull/8992

From jwilhelm at openjdk.org  Tue Jun 21 21:59:52 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 21:59:52 GMT
Subject: RFR: Merge jdk19
Message-ID: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8287971: Throw exception for missing values in .jpackage.xml
 - 8288761: SegmentAllocator:allocate(long bytesSize) not throwing IAEx when bytesSize < 0
 - 8288754: GCC 12 fails to build zReferenceProcessor.cpp
 - 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed"
 - 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp
 - 8288532: additional review changes for JDK-8286830
 - 8288139: JavaThread touches oop after GC barrier is detached
 - 8288497: add support for JavaThread::is_oop_safe()
 - 8288531: Empty spans in mobile navigation markup
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9f8bfab2...cfe52474

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9227/files
  Stats: 363 lines in 31 files changed: 197 ins; 103 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/9227.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9227/head:pull/9227

PR: https://git.openjdk.org/jdk/pull/9227

From jwilhelm at openjdk.org  Tue Jun 21 22:31:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 22:31:21 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
References: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
Message-ID: <RtaEXqQm-pqlRMf5SwzmWrI4faWuklOfogNFfyYKL1c=.6de8258d-90ed-4d1d-9980-9fad2bf82a93@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson 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 106 additional commits since the last revision:

 - Merge
 - 8288537: Move Devirtualizer out of hotspot/share/memory/iterator.hpp
   
   Reviewed-by: stefank, coleenp
 - 8288599: com/sun/management/OperatingSystemMXBean/TestTotalSwap.java: Expected total swap size ... but getTotalSwapSpaceSize returned ...
   
   Reviewed-by: sspitsyn, kevinw
 - 8288687: (fc) Unix version ofFileChannelImpl.transferTo0() should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
   
   Reviewed-by: alanb
 - 8288209: SSL debug message wrong about unsupported authentication scheme
   
   Reviewed-by: djelinski, jnimeh
 - 8288628: Unnecessary Hashtable usage in ConditionalSpecialCasing
   
   Reviewed-by: naoto, jpai
 - 8288556: VM crashes if it gets sent SIGUSR2 from outside
   
   Reviewed-by: dholmes, lucy
 - 8288724: Prevent NullPointerException in serviceability/tmtools/jstack/DaemonThreadTest.java if jstack process fails
   
   Reviewed-by: kevinw, sspitsyn
 - 8288601: Consolidate static/dynamic archive tables
   
   Reviewed-by: ccheung
 - 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run
   
   Reviewed-by: dfuchs, aefimov
 - ... and 96 more: https://git.openjdk.org/jdk/compare/af364408...cfe52474

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9227/files
  - new: https://git.openjdk.org/jdk/pull/9227/files/cfe52474..cfe52474

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9227&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9227.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9227/head:pull/9227

PR: https://git.openjdk.org/jdk/pull/9227

From jwilhelm at openjdk.org  Tue Jun 21 22:31:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 21 Jun 2022 22:31:21 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
References: <FRl67mbh6zBtta22R4P7yIgj8zSNPl2JmES8nC0QwVg=.97f16219-09d7-428d-a556-093fa8a5071f@github.com>
Message-ID: <yFzJU6fug3J4v60tnn2oT0UC9nhK5diQbd0HFMPfxoM=.60efcd4b-f255-46b9-8bed-ec6534fd7dca@github.com>

On Tue, 21 Jun 2022 21:47:17 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 2bf5c9a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bf5c9a6877b51377a535c6021a9e38549c89029
Stats:     363 lines in 31 files changed: 197 ins; 103 del; 63 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9227

From coleenp at openjdk.org  Tue Jun 21 23:02:49 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 23:02:49 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More GHA fixes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/5533cd46..a7eb45ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=05-06

  Stats: 4 lines in 4 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

PR: https://git.openjdk.org/jdk/pull/9218

From dcubed at openjdk.org  Tue Jun 21 23:31:39 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 23:31:39 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
Message-ID: <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>

On Tue, 21 Jun 2022 23:02:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

My three fixes have been sync'ed from JDK19 to JDK20.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Tue Jun 21 23:44:28 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 23:44:28 GMT
Subject: RFR: 8288752: Split thread implementation files [v8]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <SAJZNym-6_2sTPVBfDjMI2j0xckEbKk0D891VW1b0IY=.77664d6b-a064-4d67-8589-b7cceeb13b4e@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Add new files again
 - Merge branch 'master' into thread
 - More GHA fixes.
 - More GHA fixes.
 - More GHA fixes.
 - More GHA fixes.
 - Fix more GHA builds which are slightly different than what we do internally.
 - Fix Shenandoah build.
 - Remove more includes, alphatize forward declarations.
 - Make compile on all platforms (including ppc, s390 and zero)
 - ... and 5 more: https://git.openjdk.org/jdk/compare/2bf5c9a6...2eda69f4

-------------

Changes: https://git.openjdk.org/jdk/pull/9218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=07
  Stats: 10904 lines in 383 files changed: 5517 ins; 5188 del; 199 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 01:05:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 01:05:47 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Merge and testing in progress.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/2eda69f4..d7c5c936

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 01:05:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 01:05:47 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>
Message-ID: <ihrUHskGOko09Ija5pjqwriCSupUkFcHc6GqarTXwXM=.9c470418-dbe0-4e01-b48a-e8bc9dd3f227@github.com>

On Tue, 21 Jun 2022 23:28:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> My three fixes have been sync'ed from JDK19 to JDK20.

@dcubed-ojdk Your changes are now in threads.cpp and javaThread.cpp/hpp.  Can you have a look to make sure they're correct?  They were straightforward to move.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From ksakata at openjdk.org  Wed Jun 22 01:53:53 2022
From: ksakata at openjdk.org (Koichi Sakata)
Date: Wed, 22 Jun 2022 01:53:53 GMT
Subject: RFR: 8280472: Don't mix legacy logging with UL
In-Reply-To: <CS9Ss9ECb-swrKB4RypFmTsW8TlHz8Pr_zJTFAzk9mc=.fc3f348d-730c-4c34-91b7-651c74802b57@github.com>
References: <CS9Ss9ECb-swrKB4RypFmTsW8TlHz8Pr_zJTFAzk9mc=.fc3f348d-730c-4c34-91b7-651c74802b57@github.com>
Message-ID: <vEAR3UdJ_EbX9gv8I-aSAbwGlIZ1kr_s4O7L87sFJLE=.391d6101-299a-42f8-961f-20c8a8c35392@github.com>

On Thu, 16 Jun 2022 01:39:33 GMT, Koichi Sakata <ksakata at openjdk.org> wrote:

> This PR remove extra conditions related to Unified Logging.
> 
> Those conditions have been left after the transition to Unified Logging. This is an only place that uses UL, Verbose and WizardMode flags together. This JBS issue suggests to remove those flags.
> 
> # Details
> At present to output target log messages needs the debug build of OpenJDK and, Verbose or WizardMode option.
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -XX:+Verbose -version
> (Omitted)
> [0.090s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.090s][info][methodhandles] {method}
> [0.090s][info][methodhandles]  - this oop:          0x00000001303d6238
> [0.090s][info][methodhandles]  - method holder:     public synchronized abstract 'java/lang/invoke/MethodHandle'
> (Omitted)
> [0.090s][info][methodhandles]  - signature handler: 0x0000000000000000
> [0.090s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.090s][info][methodhandles]  - this oop:          0x00000001303d6238
> 
> Target log messages are from `{method}` to `- signature handler`.
> 
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
> (Omitted)
> [0.134s][info][methodhandles] lookup_polymorphic_method linkToStatic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; => basic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.134s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.134s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.134s][info][methodhandles]  - this oop:          0x000000012abd5e58
> 
> When those flags are off, UL doesn't output them. 
> 
> # Test
> There is no test code for it. So I built and run OpenJDK to confirm log output by myself.
> 
> ## Run with Log Level DEBUG After Applying This Patch
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=debug -version
> (Omitted)
> [0.132s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.132s][debug][methodhandles] {method}
> [0.132s][debug][methodhandles]  - this oop:          0x00000001217d6b98
> (Omitted)
> [0.132s][debug][methodhandles]  - signature handler: 0x0000000000000000
> [0.132s][info ][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.132s][info ][methodhandles]  - this oop:          0x00000001217d6b98
> 
> UL outputted target log messages with the debug level. It was successful.
> 
> ## Run with Log Level INFO After Applying This Patch
> 
> $ jdk/build/macosx-aarch64-server-fastdebug/jdk/bin/java -Xlog:methodhandles=info -version
> (Omitted)
> [0.086s][info][methodhandles] make_method_handle_intrinsic MH.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;
> [0.086s][info][methodhandles] lookup_polymorphic_method => intrinsic {method}
> [0.086s][info][methodhandles]  - this oop:          0x000000011f7d69f8
> 
> UL didn't output them. That was as I intended.

Thank you for the review, David. I'm always grateful for your advice.

I keep it as is for now.

-------------

PR: https://git.openjdk.org/jdk/pull/9175

From duke at openjdk.org  Wed Jun 22 03:01:36 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Jun 2022 03:01:36 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add comparison for direct value of compare

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9068/files
  - new: https://git.openjdk.org/jdk/pull/9068/files/b5627135..0ab881ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9068&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9068&range=01-02

  Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9068.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9068/head:pull/9068

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Wed Jun 22 03:01:37 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 22 Jun 2022 03:01:37 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <yEpPoRr2VaIYoQ69FtoVXgtI2e2psS2LpdQOuGHgTzI=.0f1efe28-f560-48f1-b327-182c888d14fa@github.com>
 <S4ek0_dLqaSUzE5L4pz_bLmffegMhjPw8N3GHIW2eVc=.23cfbd7d-2c88-42fe-ab2a-a314e278cfb0@github.com>
Message-ID: <46lhnsDuITWou5doLCpqWXKDsJzHVaptYMjXfjxUICk=.041b084c-b2ef-4108-a5ac-8e86ec64e819@github.com>

On Fri, 10 Jun 2022 00:05:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I have added a benchmark for the intrinsic. The result is as follows, thanks a lot:
>> 
>>                                                     Before          After
>>     Benchmark                 (size)  Mode  Cnt  Score   Error  Score   Error  Units
>>     Integers.compareUnsigned     500  avgt   15  0.527 ? 0.002  0.498 ? 0.011  us/op
>>     Longs.compareUnsigned        500  avgt   15  0.677 ? 0.014  0.561 ? 0.006  us/op
>
> @merykitty Could you please also add the micro benchmark where compareUnsigned result is stored directly in an integer and show the performance of that?

Thanks @sviswa7 for the suggestion, the results of getting the value of `compareUnsigned` directly is as follow:

                                                           Before          After
    Benchmark                       (size)  Mode  Cnt   Score   Error  Score   Error  Units
    Integers.compareUnsignedDirect     500  avgt   15   0.639 ? 0.022  0.626 ? 0.002  us/op
    Longs.compareUnsignedDirect        500  avgt   15   0.672 ? 0.011  0.609 ? 0.004  us/op

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From iklam at openjdk.org  Wed Jun 22 06:31:29 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 06:31:29 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom
Message-ID: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>

Some header files introduced in loom has unnecessary #includes. 

Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

-------------

Commit messages:
 - fixed GHA
 - step2
 - temp

Changes: https://git.openjdk.org/jdk/pull/9231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288935
  Stats: 91 lines in 11 files changed: 45 ins; 42 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9231.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9231/head:pull/9231

PR: https://git.openjdk.org/jdk/pull/9231

From dholmes at openjdk.org  Wed Jun 22 06:55:06 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jun 2022 06:55:06 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <DxINUGo2aRkKDmW6suUVAb5elJZsv_dAPo-KtfVr6Ps=.2044e3e5-9f6d-4302-938d-2958f695ee71@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

I'm okay with this in current form.

I'll leave it to Dan to decide whether he thinks restoring the old TLH "invariant" should be done in a separate RFE.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8992

From rehn at openjdk.org  Wed Jun 22 07:46:41 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 22 Jun 2022 07:46:41 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom
In-Reply-To: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
Message-ID: <o-2vWTV6sjKPlBVJhETDM7NHuixuesQ0lqv_V2jYCWQ=.5d583e05-9d75-41ec-b0d7-7ac5f5ca1945@github.com>

On Wed, 22 Jun 2022 05:55:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some header files introduced in loom has unnecessary #includes. 
> 
> Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

Thanks, looks good.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9231

From stuefe at openjdk.org  Wed Jun 22 08:04:40 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Jun 2022 08:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <EnoOI4SgAKo2uKQcZskMiuT_TALi8eR9eS2By9bm73A=.e5d92655-b034-4ced-b694-7084475cdd38@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

I like this a lot :) Thanks for doing this. I put this into our CI, just to be sure, but since Aleksey added most of our platforms to GHAs I don't expect any surprises.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From stefank at openjdk.org  Wed Jun 22 09:13:01 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jun 2022 09:13:01 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v5]
In-Reply-To: <vyxq86PlYrngnE9wAK1BW3eWomMKFeiOSeadYu_vH6M=.15443454-ce6e-4208-8d4f-a92e4fcf6663@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <vyxq86PlYrngnE9wAK1BW3eWomMKFeiOSeadYu_vH6M=.15443454-ce6e-4208-8d4f-a92e4fcf6663@github.com>
Message-ID: <lc1C8NbeUa0ihBIMVY2efszmftLbY-nyte3ZW4oC_kc=.ffd5e8ad-6d67-42c2-bd5a-20580d98bc15@github.com>

On Tue, 21 Jun 2022 19:56:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved to runtime/continuationJavaClasses.hpp

I started to add comments to the PR, but then realized it would be easier to just provide a patch with my suggestions. Please take a look at:
https://urldefense.com/v3/__https://github.com/stefank/jdk/tree/pr_9191__;!!ACWV5N9M2RV99hQ!OI4KOm69b7ILJr6be1-p_qpFme84ViIOfZNpCKbQdy8CrsqYt9FfImq-I-J7sSBntHWNpiXB3JdL5Y8P4npwgCk$ 

src/hotspot/share/classfile/continuationJavaClasses.inline.hpp line 32:

> 30: #include "oops/access.inline.hpp"
> 31: #include "oops/stackChunkOop.inline.hpp"
> 32: #include "runtime/continuationJavaClasses.hpp"

The .inline.hpp files should include the corresponding .hpp file as the first included file. This is a fairly recently addition to the style guide, that we did to resolve the compilation problems with circular dependencies between the .inline.hpp files. So, please change this to:

#include "runtime/continuationJavaClasses.hpp"

#include "classfile/javaClasses.hpp"
#include "logging/log.hpp"
#include "oops/access.inline.hpp"
#include "oops/stackChunkOop.inline.hpp"

src/hotspot/share/classfile/javaClasses.inline.hpp line 220:

> 218: }
> 219: #endif // INCLUDE_JFR
> 220: 

Spurious newline

src/hotspot/share/classfile/javaClassesImpl.hpp line 64:

> 62:   JavaClasses::compute_offset(offset, klass, name, vmSymbols::signature(), is_static)
> 63: 
> 64: 

spurious newline

src/hotspot/share/runtime/continuationJavaClasses.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include "classfile/javaClasses.hpp"

Why is classfile/javaClasses.hpp included in this file?

src/hotspot/share/runtime/continuationJavaClasses.hpp line 26:

> 24: 
> 25: #ifndef SHARE_CLASSFILE_CONTINUATIONJAVACLASSES_HPP
> 26: #define SHARE_CLASSFILE_CONTINUATIONJAVACLASSES_HPP

Include guard needs to be updated.

src/hotspot/share/runtime/continuationJavaClasses.hpp line 29:

> 27: 
> 28: #include "memory/allStatic.hpp"
> 29: #include "oops/oop.hpp"

oop isn't used in this function, include oopsHierarchy.hpp instead. This file should also include globalDefinitions.hpp and macros.hpp

-------------

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9191

From stefank at openjdk.org  Wed Jun 22 09:13:04 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jun 2022 09:13:04 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
Message-ID: <ufQnkRpgNvGlAIbV0M-v2aGc_e60CvhQbQFPJnPDUsg=.e9439914-8a0a-4dee-a92e-b47b99e895ce@github.com>

On Thu, 16 Jun 2022 22:23:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added missing includes that were hidden by previously unnedded includes

src/hotspot/share/classfile/continuationJavaClasses.cpp line 1:

> 1: /*

This file should also move to runtime/

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From stefank at openjdk.org  Wed Jun 22 09:13:06 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jun 2022 09:13:06 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v2]
In-Reply-To: <yLHYSPYU9YHMTfnWLYIX66sFwBHFi8IXtUztYECREuw=.8945fb97-363b-4e93-8863-ae1f89313c07@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <g5-Lh73rRBKBCj3TPlORoX9n09Zlx3kxh6f99wbPBHk=.49296032-fa47-4d18-af85-de4ee61f2ee7@github.com>
 <yLHYSPYU9YHMTfnWLYIX66sFwBHFi8IXtUztYECREuw=.8945fb97-363b-4e93-8863-ae1f89313c07@github.com>
Message-ID: <2xBC0uXW0Z2ZnVto-qq2B6gsE8-UJZLdEdrO83SZjCY=.a2189756-d5d5-4888-8718-301d90c06cfe@github.com>

On Fri, 17 Jun 2022 08:35:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing includes that were hidden by previously unnedded includes
>
> src/hotspot/share/classfile/continuationJavaClasses.inline.hpp line 26:
> 
>> 24: 
>> 25: #ifndef SHARE_CLASSFILE_JDK_INTERNAL_VM_STACKCHUNK_INLINE_HPP
>> 26: #define SHARE_CLASSFILE_JDK_INTERNAL_VM_STACKCHUNK_INLINE_HPP
> 
> This include guard doesn't follow the current naming convention.

This has not been resolved.

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From stefank at openjdk.org  Wed Jun 22 09:17:52 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Jun 2022 09:17:52 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom
In-Reply-To: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
Message-ID: <3Tyj243x9WvDw5n7o0uej4X2ytcAHxO1WGKWvWdNBo4=.5483cea9-d2ad-462d-9f3a-171d98b9b881@github.com>

On Wed, 22 Jun 2022 05:55:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some header files introduced in loom has unnecessary #includes. 
> 
> Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

Looks good. I saw one obvious missing include.

src/hotspot/share/runtime/continuationEntry.inline.hpp line 31:

> 29: 
> 30: #include "oops/access.hpp"
> 31: #include "runtime/frame.hpp"

Needs utilities/align.hpp

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9231

From duke at openjdk.org  Wed Jun 22 11:55:22 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Wed, 22 Jun 2022 11:55:22 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets outside
 small CodeCache
Message-ID: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>

`relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range.

### Solution
Runtime call sites are always in CodeCache. In case of a target outside small CodeCache, we can find the start of the longest possible branch from CodeCache. Then we check with `reachable_from_branch_at` whether a target is reachable. If not, a trampoline is needed.

### Testing
It is tested with the release and fastdebug builds. Release builds have the maximum possible branch range 128M. Fastdebug builds have it 2M for the purpose of testing trampolines.
Results:
- `gtest`: Passed
- `tier1`: Passed

-------------

Commit messages:
 - 8286314: Trampoline not created for far runtime targets outside small CodeCache

Changes: https://git.openjdk.org/jdk/pull/9235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286314
  Stats: 17 lines in 1 file changed: 15 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9235.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9235/head:pull/9235

PR: https://git.openjdk.org/jdk/pull/9235

From dholmes at openjdk.org  Wed Jun 22 12:12:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jun 2022 12:12:58 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <r225x-ZzIB9XNV8XG_1t7b3igFT-5SmqR3al4-hEiXg=.b3453101-21d2-47e9-89b6-87d4159bf22a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 12:33:56 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:33:56 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <_nyxGukdOlO4uHbjFawmB4DdiMzrdzKdPFLc22m9ZnI=.f5fd94ad-ab38-4b59-aa34-81a3a6eecaf8@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Thank you Thomas.  All GHA finally passed as well as my internal testing.  I'm going to update the copyrights and push it before there's a conflict.  I apologize to anyone currently making changes to thread.cpp/hpp.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 12:50:57 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:50:57 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Guidance says no copyright update. Thanks for reviewing.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 12:53:59 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:53:59 GMT
Subject: Integrated: 8288752: Split thread implementation files
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <bH2v_chVzX9woOhmVjScWGxz1hI2cviho17DfC-IAg0=.0be462a6-8fcd-47e1-85b2-483ce44aa4b9@github.com>

On Mon, 20 Jun 2022 15:49:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

This pull request has now been integrated.

Changeset: 270cf67e
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/270cf67e5ff19b082f710d52831f436dd144d883
Stats:     10905 lines in 383 files changed: 5518 ins; 5188 del; 199 mod

8288752: Split thread implementation files

Reviewed-by: dholmes, rehn, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From duke at openjdk.org  Wed Jun 22 13:00:53 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Wed, 22 Jun 2022 13:00:53 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
Message-ID: <1PUn88OKIt5c2AqFwnerbQt3djKc_mpW3znzaEnWbEQ=.2b8f458a-0a63-48cd-9822-85ab64c5ba66@github.com>

On Wed, 22 Jun 2022 11:50:36 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range.
> 
> ### Solution
> Runtime call sites are always in CodeCache. In case of a target outside small CodeCache, we can find the start of the longest possible branch from CodeCache. Then we check with `reachable_from_branch_at` whether a target is reachable. If not, a trampoline is needed.
> 
> ### Testing
> It is tested with the release and fastdebug builds. Release builds have the maximum possible branch range 128M. Fastdebug builds have it 2M for the purpose of testing trampolines.
> Results:
> - `gtest`: Passed
> - `tier1`: Passed

Hi Andrew(@theRealAph),
Could you please review the fix?

Thank you,
Evgeny

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From aph at openjdk.org  Wed Jun 22 13:28:39 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Jun 2022 13:28:39 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
Message-ID: <kRnKuNHHq0dnnXt4LqD0jzC6jrlRTzGLDQnEy1qPwJI=.7c622041-99c7-4241-bf4a-33c023dbbdf2@github.com>

On Wed, 22 Jun 2022 11:50:36 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range.
> 
> ### Solution
> Runtime call sites are always in CodeCache. In case of a target outside small CodeCache, we can find the start of the longest possible branch from CodeCache. Then we check with `reachable_from_branch_at` whether a target is reachable. If not, a trampoline is needed.
> 
> ### Testing
> It is tested with the release and fastdebug builds. Release builds have the maximum possible branch range 128M. Fastdebug builds have it 2M for the purpose of testing trampolines.
> Results:
> - `gtest`: Passed
> - `tier1`: Passed

Looks good. Nice commenting too.

I guess we'll need backports. Has this bug ever materialized on old releases?

-------------

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9235

From shade at openjdk.org  Wed Jun 22 16:31:53 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jun 2022 16:31:53 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
In-Reply-To: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
References: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
Message-ID: <kIS9imimEULJaLwJH6HAIAOoH8f9nQYPK6fo50J7FSY=.d9bed912-3f53-49eb-99a1-f734507b4f5c@github.com>

On Mon, 20 Jun 2022 17:58:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure:
> 
> 
> In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29,
>                  from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28,
>                  from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34:
> In function 'const void* memchr(const void*, int, size_t)',
>     inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32,
>     inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6,
>     inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19:

Any takers? :)

-------------

PR: https://git.openjdk.org/jdk19/pull/49

From xliu at openjdk.org  Wed Jun 22 16:53:03 2022
From: xliu at openjdk.org (Xin Liu)
Date: Wed, 22 Jun 2022 16:53:03 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
Message-ID: <efFJ77TMBFVUSOnTzx7VBtzuqsQqMMYgVHKHBtMnTZs=.a74e2f0e-c246-473b-91ea-5d2a25fbc12b@github.com>

On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.
> 
> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.
> 
> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.
> 
> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 
> 
> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.
> 
> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."
> 
> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.
> 
> ----
> 
> Testing:
> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch

I take a look at linux_arm directory. All functions come in pair(.global and .type function).  so it's reasonable.  LGTM. I am not a reviewer. we still need other reviewer to approve it.

src/hotspot/os_cpu/linux_arm/safefetch_linux_arm.S line 29:

> 27:     .globl _SafeFetch32_fault
> 28:     .globl _SafeFetch32_continuation
> 29:     .type SafeFetch32_impl, %function

By adding this .type directive, the compiler knows that SafeFetch32_impl is a function. 
When static linker resolves it, it will update the correct branch instruction according to its target. In this case, it will use BX on Ubuntu18.04. 

Is my understanding correct?

-------------

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.org/jdk/pull/9213

From sspitsyn at openjdk.org  Wed Jun 22 17:00:56 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Jun 2022 17:00:56 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
Message-ID: <8SYAegvb_fzIcGea5qdXY3TfM0FL1-H3OJk5un-0LBw=.b5508b47-1066-4037-b2d5-9c8d2a3e8860@github.com>

On Tue, 21 Jun 2022 19:34:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove _depth == 0 clause from sanity check assert
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java line 103:
> 
>> 101:         GetSetLocalTest obj = new GetSetLocalTest();
>> 102: 
>> 103:         for (int i = 0; i < 1000; i++) {
> 
> Does this test still run quickly?

No, it does not run quickly. However, this fix is needed to reproduce the issue.
In fact, it is to reproduce one more rare reproduceble issue:
8286836 Crash in serviceability/jvmti/vthread/GetSetLocalTest: No support for deferred values in continuations

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From aph at openjdk.org  Wed Jun 22 17:08:21 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Jun 2022 17:08:21 GMT
Subject: RFR: 8288992: AArch64: CMN should be handled the same way as CMP
Message-ID: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>

At present, `cmp(r8, -1)` fails at compile time, but `cmn(r8, -1)` fails at runtime. We should fix cmn() to be the same as `cmp()`. 

After this change, it's much less likely that we'll be surprised by immediate overflows in `cmn()`.

-------------

Commit messages:
 - 8288992: AArch64: CMN should be handled the same way as CMP

Changes: https://git.openjdk.org/jdk/pull/9246/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9246&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288992
  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9246.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9246/head:pull/9246

PR: https://git.openjdk.org/jdk/pull/9246

From phh at openjdk.org  Wed Jun 22 17:09:54 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 22 Jun 2022 17:09:54 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
Message-ID: <IKpSn-1htgMFIOKZh0XXL3n8hnouy_rZJC4upZGaFYY=.e140b5aa-287d-49b8-85a1-fa432874ff98@github.com>

On Wed, 22 Jun 2022 11:50:36 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range.
> 
> ### Solution
> Runtime call sites are always in CodeCache. In case of a target outside small CodeCache, we can find the start of the longest possible branch from CodeCache. Then we check with `reachable_from_branch_at` whether a target is reachable. If not, a trampoline is needed.
> 
> ### Testing
> It is tested with the release and fastdebug builds. Release builds have the maximum possible branch range 128M. Fastdebug builds have it 2M for the purpose of testing trampolines.
> Results:
> - `gtest`: Passed
> - `tier1`: Passed

Lgtm.

MacOS debug build failure looks unrelated.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9235

From iklam at openjdk.org  Wed Jun 22 17:30:09 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 17:30:09 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v6]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <gZ363yBU3aRJtsZbwZJESVLU3Plhq5Bn1reSxWJTers=.51a48e93-de24-458d-ba51-af46b7e9fdbb@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/9d998d7a..2012fc68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=04-05

  Stats: 49 lines in 14 files changed: 20 ins; 11 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

PR: https://git.openjdk.org/jdk/pull/9191

From iklam at openjdk.org  Wed Jun 22 18:10:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 18:10:43 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom [v2]
In-Reply-To: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
Message-ID: <hmM3JKuGtCUtH8ULmO42E6ql69cTMitoNvSvEAOqTKY=.b3251e71-81ef-4a1a-b610-249a1d511ea3@github.com>

> Some header files introduced in loom has unnecessary #includes. 
> 
> Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8288935-fix-loom-excessive-includes
 - @stefank comments
 - fixed GHA
 - step2
 - temp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9231/files
  - new: https://git.openjdk.org/jdk/pull/9231/files/59ae33d6..72db1c0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9231&range=00-01

  Stats: 22957 lines in 484 files changed: 5813 ins; 7642 del; 9502 mod
  Patch: https://git.openjdk.org/jdk/pull/9231.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9231/head:pull/9231

PR: https://git.openjdk.org/jdk/pull/9231

From iklam at openjdk.org  Wed Jun 22 18:12:38 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 18:12:38 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v7]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <4pVA1eJBFTYsLMIt2WKthqnrY0xpzCn2cw-0DaWMPJw=.c944ac48-7c34-49f0-8cc1-d496c67b4c42@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - added missing javaClasses.inline.hpp after merge with javaThread.hpp split
 - Merge branch 'master' into 8288623-move-continuation-out-of-javaClasses-hpp
 - Review comments
 - moved to runtime/continuationJavaClasses.hpp
 - @stefank review comments
 - fixed include guard macro and copyright year
 - added missing includes that were hidden by previously unnedded includes
 - 8288623: Move Continuation classes out of javaClasses.hpp

-------------

Changes: https://git.openjdk.org/jdk/pull/9191/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=06
  Stats: 1062 lines in 24 files changed: 600 ins; 447 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

PR: https://git.openjdk.org/jdk/pull/9191

From iklam at openjdk.org  Wed Jun 22 18:12:38 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 18:12:38 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <DKTBMylz4j__VRfHkVdU_6VN1AagkOUovnRHa7_xBL0=.69ce82e8-5c82-4417-b6dd-dc7c0187b773@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
 <DKTBMylz4j__VRfHkVdU_6VN1AagkOUovnRHa7_xBL0=.69ce82e8-5c82-4417-b6dd-dc7c0187b773@github.com>
Message-ID: <Y2ZuNq4DmHjxpqVsm4f4RO8MvKQgghGDCR1MyvuktBo=.4712f04d-9db4-4661-b42e-8130b7498f1a@github.com>

On Fri, 17 Jun 2022 20:18:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed include guard macro and copyright year
>
> I've talked to Ioi and Coleen about whether `javaClasses` or `continuations` should be considered as the most relevant subsystem. Their take is that `continuations` is. I'm warming up to that thought, but I think I'd then would prefer if continuationsJavaClasses.hpp etc. get moved to where the other continuation files are, in the runtime/ directory.

Hi @stefank, thank you so much for providing the additional fixes. I have incorporated them into my PR and also synced with Coleen's javaThread.hpp split PR (#9218). Doing more thorough build testing now.

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From dcubed at openjdk.org  Wed Jun 22 19:30:42 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 19:30:42 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
Message-ID: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>

On Tue, 21 Jun 2022 23:02:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

Sorry for the late review. I decided to try a crawl-thru review with this PR
and managed to get 1/3 done yesterday and the rest done today.

I very much like this PR. I think there's only one comment that will require a cleanup.

src/hotspot/cpu/zero/stack_zero.cpp line 29:

> 27: #include "interpreter/interpreterRuntime.hpp"
> 28: #include "interpreter/zero/bytecodeInterpreter.hpp"
> 29: #include "runtime/javaThread.hpp"

Interesting... This replacement of thread.inline.hpp to javaThread.hpp also
has an include javaThread.inline.hpp. There are other thread.inline.hpp to
javaThread.hpp replacements that don't add an include of javaThread.inline.hpp.

Did you only add javaThread.inline.hpp when compilation failed?

src/hotspot/share/prims/jvmtiDeferredUpdates.hpp line 36:

> 34: template <typename T> class GrowableArray;
> 35: 
> 36: class jvmtiDeferredLocalVariable : public CHeapObj<mtCompiler> {

This surprised me, but I'm guessing we picked up the template
from thread.inline.hpp...

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 39:

> 37: #include "runtime/safepointMechanism.inline.hpp"
> 38: #include "runtime/safepointVerifiers.hpp"
> 39: #include "runtime/javaThread.inline.hpp"

This is a duplicate include of the one on L33 above.

src/hotspot/share/runtime/vframe.hpp line 116:

> 114: };
> 115: 
> 116: class MonitorInfo;

This one also surprise me. I don't have a guess how this one worked before.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9218

From dcubed at openjdk.org  Wed Jun 22 20:04:57 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 20:04:57 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
 <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>
Message-ID: <1wGBDihKF58QXO4N0_mxsmCR8Z53RIoxX31ds7oZit4=.74152b42-6386-4db1-988a-a4e204f02c03@github.com>

On Wed, 22 Jun 2022 12:47:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge and testing in progress.
>
> Guidance says no copyright update. Thanks for reviewing.

@coleenp's comment from above:
> @dcubed-ojdk Your changes are now in threads.cpp and javaThread.cpp/hpp.
> Can you have a look to make sure they're correct? They were straightforward to move.

I double checked each of the three patches and all the changes are there and in
the right places. What was really cool was being able to pick between the javaThread.*,
thread.* and threads.* files easily based on the class name for the function that I
was changing. Pretty easy to navigate the new layout (IMHO).

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 21:04:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <GlzsoqgfEb_Yo63X--aVa6vYTthb9fVdQflnro19qbo=.a862c90b-6c44-4ec4-981b-6a00e17287d6@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Hi Dan, thank you for crawling through the change.  I'm going to make your comments into a new CR and fix it there.
Sorry I didn't wait for the integration.  I was anxious about merging and finally getting GHA to pass.  I'm glad you liked the changes!

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 21:04:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
Message-ID: <te2IS0G-YtpjcN2T3i9f5qNM6jyC0jt5Mn4PStd0PIc=.1ca43a32-8ad2-4f92-a028-c0c41dd9b6ea@github.com>

On Wed, 22 Jun 2022 19:06:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> src/hotspot/share/prims/jvmtiDeferredUpdates.hpp line 36:
> 
>> 34: template <typename T> class GrowableArray;
>> 35: 
>> 36: class jvmtiDeferredLocalVariable : public CHeapObj<mtCompiler> {
> 
> This surprised me, but I'm guessing we picked up the template
> from thread.inline.hpp...

yes.

> src/hotspot/share/runtime/vframe.hpp line 116:
> 
>> 114: };
>> 115: 
>> 116: class MonitorInfo;
> 
> This one also surprise me. I don't have a guess how this one worked before.

That forward declaration came from a transitive include of thread.hpp, if I remember correctly.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From coleenp at openjdk.org  Wed Jun 22 21:09:39 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:09:39 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
Message-ID: <jlvU-FB1HYbMFJ163V7JNLwlbKy9AXSh03m5Oe0mYOs=.d4067eb0-945e-47fa-b4c4-13ab404af1d7@github.com>

On Tue, 21 Jun 2022 23:38:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> src/hotspot/cpu/zero/stack_zero.cpp line 29:
> 
>> 27: #include "interpreter/interpreterRuntime.hpp"
>> 28: #include "interpreter/zero/bytecodeInterpreter.hpp"
>> 29: #include "runtime/javaThread.hpp"
> 
> Interesting... This replacement of thread.inline.hpp to javaThread.hpp also
> has an include javaThread.inline.hpp. There are other thread.inline.hpp to
> javaThread.hpp replacements that don't add an include of javaThread.inline.hpp.
> 
> Did you only add javaThread.inline.hpp when compilation failed?

Yes, I added javaThread.inline.hpp after compilation failed.  I will remove javaThread.hpp.

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 39:
> 
>> 37: #include "runtime/safepointMechanism.inline.hpp"
>> 38: #include "runtime/safepointVerifiers.hpp"
>> 39: #include "runtime/javaThread.inline.hpp"
> 
> This is a duplicate include of the one on L33 above.

Thanks, that was unintentional.  Removed.

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From dcubed at openjdk.org  Wed Jun 22 21:14:41 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 21:14:41 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <4PjPxF1me-KnvwbACwKuZNm74D3rHA8LnICxB72f_Do=.861b1703-e3f3-40e8-a982-0b5a0fa29a0a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

No apology needed. It was a huge change and you don't want to wait too long
and run into merge after merge...

-------------

PR: https://git.openjdk.org/jdk/pull/9218

From sspitsyn at openjdk.org  Wed Jun 22 21:27:51 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Jun 2022 21:27:51 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
Message-ID: <LhKPN0FiGW2-owr5WBxmHOoSdaArF9BrtWi2SYIdC30=.c2ec3ef8-f956-4a4c-825c-350cfbd2930c@github.com>

On Tue, 21 Jun 2022 19:34:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove _depth == 0 clause from sanity check assert
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 647:
> 
>> 645:   }
>> 646:   if (_set) {
>> 647:     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
> 
> It would be good to elaborate a bit more on this check. Say something about it being a "safepoint poll on return in the oldest thawed frame", and why that is a problem.

Okay. I'd suggest this:

  if (_set) {
    if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
      assert(Continuation::is_frame_in_continuation(_jvf->thread(), fr), "sanity check");
      // The topmost frame of a mounted continuation can still be in the heap. This code is executed at safepoint.
      // The safepoint could be as we return to the return barrier but before we execute it (poll return).
      _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
      return;
    }

Is it more clear?

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From iklam at openjdk.org  Wed Jun 22 22:23:37 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 22:23:37 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v8]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <MTL9lzwutDSxVJauakQ7AwsPGj1nqwsrao26oyZf4wA=.c494ca90-261f-48ca-b188-1feae558cc29@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed GHA build failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/6798bb4d..9adf490d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=06-07

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

PR: https://git.openjdk.org/jdk/pull/9191

From iklam at openjdk.org  Wed Jun 22 22:32:22 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 22 Jun 2022 22:32:22 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v9]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <tlRyBkKTZl0A4WdaGPltKinuEdtqC7TzxWARmcE293k=.8657673b-3cd2-47c3-af4b-4fae7ea35fba@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  one more missing header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9191/files
  - new: https://git.openjdk.org/jdk/pull/9191/files/9adf490d..a2179280

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

PR: https://git.openjdk.org/jdk/pull/9191

From cjplummer at openjdk.org  Wed Jun 22 23:50:39 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Jun 2022 23:50:39 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <LhKPN0FiGW2-owr5WBxmHOoSdaArF9BrtWi2SYIdC30=.c2ec3ef8-f956-4a4c-825c-350cfbd2930c@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
 <LhKPN0FiGW2-owr5WBxmHOoSdaArF9BrtWi2SYIdC30=.c2ec3ef8-f956-4a4c-825c-350cfbd2930c@github.com>
Message-ID: <s1dFqe5ouDet6Y4l44Zzu69vyjLFKEiHUW1gAysu3Ns=.3823b7e2-0912-44ae-a7c0-43e9a1a5e43d@github.com>

On Wed, 22 Jun 2022 21:23:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiImpl.cpp line 647:
>> 
>>> 645:   }
>>> 646:   if (_set) {
>>> 647:     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
>> 
>> It would be good to elaborate a bit more on this check. Say something about it being a "safepoint poll on return in the oldest thawed frame", and why that is a problem.
>
> Okay. I'd suggest this:
> 
>   if (_set) {
>     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
>       assert(Continuation::is_frame_in_continuation(_jvf->thread(), fr), "sanity check");
>       // The topmost frame of a mounted continuation can still be in the heap. This code is executed at safepoint.
>       // The safepoint could be as we return to the return barrier but before we execute it (poll return).
>       _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
>       return;
>     }
> 
> Is it more clear?

I guess what I'm not understanding here is how/why "fr.is_heap_frame())" translates into "we are not single stepping or at a breakpoint". I know we already did the check earlier to make sure we are "depth == 0", and I understand that in this code we are handling the special case of "depth == 0" possibly not indicating we are truly in the topmost frame. From Ron's explanation, the frame has been popped, but the callee frame has not been thawed yet. Is the "fr.is_heap_frame())" check telling us the frame hasn't been thawed. If so, I would call this out in the comment. Basically say something like:

"If the topmost frame is a heap frame, then it hasn't been thawed. This can happen if we are executing at a return barrier safepoint. The callee frame has been popped, but the caller frame has not been thawed. We can't support a setlocal in the callee frame at this point, because we aren't truly in the callee yet."

Also, I think the following comment is misleading:

`deferred locals currently unsupported in continuations`

That's not true. They are supported when single stepping and at breakpoints, or more accurately, in the topmost frame. Looks like this is copy-n-paste from the following code with the same issue:


 613   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
 614     _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
 615     return;
 616   }

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From sspitsyn at openjdk.org  Thu Jun 23 00:39:42 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 00:39:42 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <s1dFqe5ouDet6Y4l44Zzu69vyjLFKEiHUW1gAysu3Ns=.3823b7e2-0912-44ae-a7c0-43e9a1a5e43d@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
 <LhKPN0FiGW2-owr5WBxmHOoSdaArF9BrtWi2SYIdC30=.c2ec3ef8-f956-4a4c-825c-350cfbd2930c@github.com>
 <s1dFqe5ouDet6Y4l44Zzu69vyjLFKEiHUW1gAysu3Ns=.3823b7e2-0912-44ae-a7c0-43e9a1a5e43d@github.com>
Message-ID: <R9QXXYVRDCedh7ndG2e7pKxdMzRl-yOZUkvKzJCcDKo=.5d28a9e0-6659-4471-9bd5-7e5aabcbc170@github.com>

On Wed, 22 Jun 2022 23:47:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I guess what I'm not understanding here is how/why "fr.is_heap_frame())" translates into "we are not single stepping or at a breakpoint". 

It is impossible to have `fr.is_heap_frame()` if we are at a single step or at a breakpoint. The frame has to be active or really executed at any event point.
I like your suggestion for the comment wording but I'm not sure if it is good enough.

> Also, I think the following comment is misleading:

I'll update this comment as well to make it more accurate.

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From coleenp at openjdk.org  Thu Jun 23 01:21:06 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 01:21:06 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split
Message-ID: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>

Remove extra include directives.  Tested with GHA.

-------------

Commit messages:
 - 8289006: Cleanup from thread.hpp split

Changes: https://git.openjdk.org/jdk/pull/9252/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289006
  Stats: 7 lines in 2 files changed: 2 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9252.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9252/head:pull/9252

PR: https://git.openjdk.org/jdk/pull/9252

From sspitsyn at openjdk.org  Thu Jun 23 01:55:50 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 01:55:50 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <R9QXXYVRDCedh7ndG2e7pKxdMzRl-yOZUkvKzJCcDKo=.5d28a9e0-6659-4471-9bd5-7e5aabcbc170@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
 <LhKPN0FiGW2-owr5WBxmHOoSdaArF9BrtWi2SYIdC30=.c2ec3ef8-f956-4a4c-825c-350cfbd2930c@github.com>
 <s1dFqe5ouDet6Y4l44Zzu69vyjLFKEiHUW1gAysu3Ns=.3823b7e2-0912-44ae-a7c0-43e9a1a5e43d@github.com>
 <R9QXXYVRDCedh7ndG2e7pKxdMzRl-yOZUkvKzJCcDKo=.5d28a9e0-6659-4471-9bd5-7e5aabcbc170@github.com>
Message-ID: <SOlYCWXO5xm3YONBm-R6Py5yvMnby3SV-4ICwApf-HI=.2826c146-f2ba-4914-ad48-94c379b9ab6e@github.com>

On Thu, 23 Jun 2022 00:36:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I guess what I'm not understanding here is how/why "fr.is_heap_frame())" translates into "we are not single stepping or at a breakpoint". I know we already did the check earlier to make sure we are "depth == 0", and I understand that in this code we are handling the special case of "depth == 0" possibly not indicating we are truly in the topmost frame. From Ron's explanation, the frame has been popped, but the callee frame has not been thawed yet. Is the "fr.is_heap_frame())" check telling us the frame hasn't been thawed. If so, I would call this out in the comment. Basically say something like:
>> 
>> "If the topmost frame is a heap frame, then it hasn't been thawed. This can happen if we are executing at a return barrier safepoint. The callee frame has been popped, but the caller frame has not been thawed. We can't support a setlocal in the callee frame at this point, because we aren't truly in the callee yet."
>> 
>> Also, I think the following comment is misleading:
>> 
>> `deferred locals currently unsupported in continuations`
>> 
>> That's not true. They are supported when single stepping and at breakpoints, or more accurately, in the topmost frame. Looks like this is copy-n-paste from the following code with the same issue:
>> 
>> 
>>  613   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
>>  614     _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
>>  615     return;
>>  616   }
>
>> I guess what I'm not understanding here is how/why "fr.is_heap_frame())" translates into "we are not single stepping or at a breakpoint". 
> 
> It is impossible to have `fr.is_heap_frame()` if we are at a single step or at a breakpoint. The frame has to be active and really executed at any event point. It can't be frozen because a native callback is executed at the top. Do you think, we should explain this as well?
> 
> I like your suggestion for the comment wording but I'm not sure if it is good enough.
> 
>> Also, I think the following comment is misleading:
> 
> I'll update this comment as well to make it more accurate.

How about this change:

git diff src/hotspot/share/prims/jvmtiImpl.cpp
diff --git a/src/hotspot/share/prims/jvmtiImpl.cpp b/src/hotspot/share/prims/jvmtiImpl.cpp
index c34558c9ad5..8a7396e3cee 100644
--- a/src/hotspot/share/prims/jvmtiImpl.cpp
+++ b/src/hotspot/share/prims/jvmtiImpl.cpp
@@ -611,7 +611,7 @@ void VM_BaseGetOrSetLocal::doit() {
 
   frame fr = _jvf->fr();
   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
-    _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
+    _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully unsupported in continuations
     return;
   }
 
@@ -646,8 +646,13 @@ void VM_BaseGetOrSetLocal::doit() {
   if (_set) {
     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
       assert(Continuation::is_frame_in_continuation(_jvf->thread(), fr), "sanity check");
-      // the safepoint could be as we return to the return barrier but before we execute it (poll return)
-      _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
+      // If the topmost frame is a heap frame, then it hasn't been thawed. This can happen
+      // if we are executing at a return barrier safepoint. The callee frame has been popped,
+      // but the caller frame has not been thawed. We can't support a JVMTI SetLocal in the callee
+      // frame at this point, because we aren't truly in the callee yet.
+      // fr.is_heap_frame() is impossible if a continuation is at a single step or breakpoint.
+      // In such cases the frames can't be frozen because a native callback frame is at the top.
+      _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully unsupported in continuations
       return;
     }

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From stuefe at openjdk.org  Thu Jun 23 03:59:54 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Jun 2022 03:59:54 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <efFJ77TMBFVUSOnTzx7VBtzuqsQqMMYgVHKHBtMnTZs=.a74e2f0e-c246-473b-91ea-5d2a25fbc12b@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
 <efFJ77TMBFVUSOnTzx7VBtzuqsQqMMYgVHKHBtMnTZs=.a74e2f0e-c246-473b-91ea-5d2a25fbc12b@github.com>
Message-ID: <VojQeKNVJOZxsLLoR-pOr44p1JETMmOm9GbFc_vx090=.5c4ea446-7cb4-4791-8dcb-bc26e873d6ba@github.com>

On Wed, 22 Jun 2022 16:50:18 GMT, Xin Liu <xliu at openjdk.org> wrote:

> I take a look at linux_arm directory. All functions come in pair(.global and .type function). so it's reasonable. LGTM. I am not a reviewer. we still need other reviewer to approve it.

Thank you, Xin!

> By adding this .type directive, the compiler knows that SafeFetch32_impl is a function. When static linker resolves it, it will update the correct branch instruction according to its target. In this case, it will use BX on Ubuntu18.04.
> 
> Is my understanding correct?

Correct.

-------------

PR: https://git.openjdk.org/jdk/pull/9213

From dholmes at openjdk.org  Thu Jun 23 06:32:43 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 23 Jun 2022 06:32:43 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split
In-Reply-To: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
Message-ID: <OtEIfurQwLDB_rWFrsyHIWxdL1rLJLnL62i5k2fApN4=.df78d00f-8f62-4c2e-b426-2c94ea336dd3@github.com>

On Wed, 22 Jun 2022 22:00:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove extra include directives.  Tested with GHA.

One pre-existing nit but your changes look good.

Thanks.

src/hotspot/cpu/zero/stack_zero.cpp line 32:

> 30: #include "runtime/javaThread.inline.hpp"
> 31: #include "stack_zero.hpp"
> 32: #include "stack_zero.inline.hpp"

Existing, but it is redundant to include the .hpp and the .inline.hpp file as the later always includes the former.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9252

From sspitsyn at openjdk.org  Thu Jun 23 07:09:38 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 07:09:38 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v3]
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - resolved 8286580 review comments; problem-listed test GetSetLocalTest under  8286836
 - Merge branch 'master' into br2
 - remove _depth == 0 clause from sanity check assert
 - 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/42/files
  - new: https://git.openjdk.org/jdk19/pull/42/files/bd1a901c..ca7c3b3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=42&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=42&range=01-02

  Stats: 845 lines in 50 files changed: 524 ins; 86 del; 235 mod
  Patch: https://git.openjdk.org/jdk19/pull/42.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/42/head:pull/42

PR: https://git.openjdk.org/jdk19/pull/42

From sspitsyn at openjdk.org  Thu Jun 23 07:09:39 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 07:09:39 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v2]
In-Reply-To: <8SYAegvb_fzIcGea5qdXY3TfM0FL1-H3OJk5un-0LBw=.b5508b47-1066-4037-b2d5-9c8d2a3e8860@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <tfYSvc1CMU1GLHGi1zCUtMSRYLFN6m7L_BTrKaV9ImY=.b2b9afe5-e9df-419a-ac9b-dfc8de846956@github.com>
 <BrlA7IMGUP4izH5aA19KusB8GEyS8-2v8CveNOj50OQ=.44dc41aa-70dd-4ad7-a66b-dcf2aa2af8a7@github.com>
 <8SYAegvb_fzIcGea5qdXY3TfM0FL1-H3OJk5un-0LBw=.b5508b47-1066-4037-b2d5-9c8d2a3e8860@github.com>
Message-ID: <zpEFr59jryXiyrKgBMja2d1HYlmG4MHGbVwSG4_hg8U=.16ab963e-e5ae-44ee-afaa-0865dc21de34@github.com>

On Wed, 22 Jun 2022 16:57:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetSetLocalTest/GetSetLocalTest.java line 103:
>> 
>>> 101:         GetSetLocalTest obj = new GetSetLocalTest();
>>> 102: 
>>> 103:         for (int i = 0; i < 1000; i++) {
>> 
>> Does this test still run quickly?
>
> No, it does not run quickly. However, this fix is needed to reproduce the issue.
> In fact, it is also to reproduce another rare reproducible issue:
> 8286836 Crash in serviceability/jvmti/vthread/GetSetLocalTest: No support for deferred values in continuations

Decided to decrease the iterations number at L103 from 1000 to 200.
I hope, it should be a little bit quicker now.

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From duke at openjdk.org  Thu Jun 23 09:17:52 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 23 Jun 2022 09:17:52 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <kRnKuNHHq0dnnXt4LqD0jzC6jrlRTzGLDQnEy1qPwJI=.7c622041-99c7-4241-bf4a-33c023dbbdf2@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
 <kRnKuNHHq0dnnXt4LqD0jzC6jrlRTzGLDQnEy1qPwJI=.7c622041-99c7-4241-bf4a-33c023dbbdf2@github.com>
Message-ID: <JOlMFNSUmeaigq3Aimos71eCavobN-p6huSHJE9nIko=.1eda9c0b-24d5-46b1-8155-05fa06c23ebd@github.com>

On Wed, 22 Jun 2022 13:25:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Looks good. Nice commenting too.

Thank you for review and feedback.

> I guess we'll need backports. Has this bug ever materialized on old releases?

I have not found any bug reports. I guess most of applications run with 240M CodeCache. Applications at risk are those which turn off tiered compilation. By default they get 48M CodeCache. They might have been lucky the whole code is within 128M range.

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From duke at openjdk.org  Thu Jun 23 09:17:53 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 23 Jun 2022 09:17:53 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <IKpSn-1htgMFIOKZh0XXL3n8hnouy_rZJC4upZGaFYY=.e140b5aa-287d-49b8-85a1-fa432874ff98@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
 <IKpSn-1htgMFIOKZh0XXL3n8hnouy_rZJC4upZGaFYY=.e140b5aa-287d-49b8-85a1-fa432874ff98@github.com>
Message-ID: <DHcdBea5z5cISr6IpsSeqvjlVchuzKimHxf0fl9uUuo=.6249cb6c-efe3-461d-9258-99b33efde39d@github.com>

On Wed, 22 Jun 2022 17:05:37 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Lgtm.

Thank you

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From lucy at openjdk.org  Thu Jun 23 09:25:57 2022
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 23 Jun 2022 09:25:57 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
Message-ID: <NSIKnUMijtd2Wfd9gLBtiMK9d4KayZQ_dX5rHxOrh5E=.3d2de30e-ea50-43b0-9da4-fcd3e98f4e69@github.com>

On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.
> 
> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.
> 
> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.
> 
> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 
> 
> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.
> 
> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."
> 
> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.
> 
> ----
> 
> Testing:
> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9213

From aph at openjdk.org  Thu Jun 23 09:34:53 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 23 Jun 2022 09:34:53 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <JOlMFNSUmeaigq3Aimos71eCavobN-p6huSHJE9nIko=.1eda9c0b-24d5-46b1-8155-05fa06c23ebd@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
 <kRnKuNHHq0dnnXt4LqD0jzC6jrlRTzGLDQnEy1qPwJI=.7c622041-99c7-4241-bf4a-33c023dbbdf2@github.com>
 <JOlMFNSUmeaigq3Aimos71eCavobN-p6huSHJE9nIko=.1eda9c0b-24d5-46b1-8155-05fa06c23ebd@github.com>
Message-ID: <o0nKZGjCl1GLZ340EecO__rTTRta3a2eSStY_t9M1KI=.d603291a-f539-4346-883a-498bb61499f3@github.com>

On Thu, 23 Jun 2022 09:13:44 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> > I guess we'll need backports. Has this bug ever materialized on old releases?
> 
> I have not found any bug reports. I guess most of applications run with 240M CodeCache. Applications at risk are those which turn off tiered compilation. By default they get 48M CodeCache. They might have been lucky the whole code is within 128M range.

OK, so I'd probably not backport, then. I know it feels a bit weird to leave a known bug, but perhaps it's better to let sleeping dogs lie. What do you think?

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From duke at openjdk.org  Thu Jun 23 09:34:55 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 23 Jun 2022 09:34:55 GMT
Subject: Integrated: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
Message-ID: <VYppj2ZNMQi-O40sjRZURVqA0_a_vfLSJZL_tfwztuU=.40d8c728-41b6-4ac0-a783-d3d31c5d63c9@github.com>

On Wed, 22 Jun 2022 11:50:36 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range.
> 
> ### Solution
> Runtime call sites are always in CodeCache. In case of a target outside small CodeCache, we can find the start of the longest possible branch from CodeCache. Then we check with `reachable_from_branch_at` whether a target is reachable. If not, a trampoline is needed.
> 
> ### Testing
> It is tested with the release and fastdebug builds. Release builds have the maximum possible branch range 128M. Fastdebug builds have it 2M for the purpose of testing trampolines.
> Results:
> - `gtest`: Passed
> - `tier1`: Passed

This pull request has now been integrated.

Changeset: bf0623b1
Author:    Evgeny Astigeevich <eastig at amazon.com>
Committer: Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf0623b11fd95f09fe953822af71d965bdab8d0f
Stats:     17 lines in 1 file changed: 15 ins; 0 del; 2 mod

8286314: Trampoline not created for far runtime targets outside small CodeCache

Reviewed-by: aph, phh

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From rehn at openjdk.org  Thu Jun 23 09:42:24 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 23 Jun 2022 09:42:24 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
Message-ID: <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>

> The current implementation do not count all monitor enter, counts high up in abstraction and causes a performance regression on aarch64 with some benchmarks due to C2 changes.
> 
> This change makes the counting exact by pushing the counting down in the abstraction.
> The additional JNI counter is strictly not needed, but enables us to figure out if we have monitors "on stack".
> 
> An uncontended lock plus unlock is 1 ns (21.5 -> 22.5) slower in C2 compiled code on x64 with the additional increment and decrement.
> 
> Fixed aarch64, x64, x86 and zero.
> 
> Passes t1-8

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into held-mon-count
 - 8286957 - PR Baseline

-------------

Changes: https://git.openjdk.org/jdk/pull/8945/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8945&range=01
  Stats: 517 lines in 43 files changed: 301 ins; 143 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/8945.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8945/head:pull/8945

PR: https://git.openjdk.org/jdk/pull/8945

From stuefe at openjdk.org  Thu Jun 23 10:18:07 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Jun 2022 10:18:07 GMT
Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <pzmFNkTHZxGi2zDKYm8e9ujG67xsLs82hf6TUTpUK4E=.b1ff5c66-c655-4d4f-8709-b7e33c93d1e1@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
 <pzmFNkTHZxGi2zDKYm8e9ujG67xsLs82hf6TUTpUK4E=.b1ff5c66-c655-4d4f-8709-b7e33c93d1e1@github.com>
Message-ID: <wUv-ItDoCQ_Alki7FuNKEzTzjRqr16fb4_hmJgb2EqQ=.697dce18-d917-4123-8930-18f192154d09@github.com>

On Mon, 20 Jun 2022 18:50:26 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

>> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.
>> 
>> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.
>> 
>> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.
>> 
>> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 
>> 
>> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.
>> 
>> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."
>> 
>> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.
>> 
>> ----
>> 
>> Testing:
>> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
>> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch
>
> Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb  even with crossbuilds. 
> LGTM

Thanks @snazarkin, @navyxliu and @RealLucy !

-------------

PR: https://git.openjdk.org/jdk/pull/9213

From stuefe at openjdk.org  Thu Jun 23 10:18:09 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 23 Jun 2022 10:18:09 GMT
Subject: Integrated: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes
 random crashes
In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com>
Message-ID: <h9dE-hoK18H0Euwzf5ji3hqglcegVy6G1idfCIPKDiw=.848a0828-8c93-45d0-a0e0-e4923995498f@github.com>

On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix.
> 
> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997.
> 
> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`.
> 
> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. 
> 
> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after.
> 
> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work."
> 
> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option.
> 
> ----
> 
> Testing:
> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default
> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch

This pull request has now been integrated.

Changeset: 26c03c18
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26c03c1860c6da450b5cd6a46576c78bea682f96
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes
8284997: arm32 build crashes since JDK-8283326

Reviewed-by: snazarki, xliu, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/9213

From duke at openjdk.org  Thu Jun 23 10:26:54 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 23 Jun 2022 10:26:54 GMT
Subject: RFR: 8286314: Trampoline not created for far runtime targets
 outside small CodeCache
In-Reply-To: <o0nKZGjCl1GLZ340EecO__rTTRta3a2eSStY_t9M1KI=.d603291a-f539-4346-883a-498bb61499f3@github.com>
References: <XjsJo4kW9BjpygMBlN7tWeioUdcQpR0sEQlLz8ktlFA=.4a11478e-3226-4390-a358-a9b34f17af5a@github.com>
 <kRnKuNHHq0dnnXt4LqD0jzC6jrlRTzGLDQnEy1qPwJI=.7c622041-99c7-4241-bf4a-33c023dbbdf2@github.com>
 <JOlMFNSUmeaigq3Aimos71eCavobN-p6huSHJE9nIko=.1eda9c0b-24d5-46b1-8155-05fa06c23ebd@github.com>
 <o0nKZGjCl1GLZ340EecO__rTTRta3a2eSStY_t9M1KI=.d603291a-f539-4346-883a-498bb61499f3@github.com>
Message-ID: <dYtWCI_mHaQfW5lRIZF2UYXPI8huwYfIGgYv-WSzoCk=.ef9711c6-ccb7-4d97-ab43-b68b5e083428@github.com>

On Thu, 23 Jun 2022 09:31:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

> OK, so I'd probably not backport, then. I know it feels a bit weird to leave a known bug, but perhaps it's better to let sleeping dogs lie. What do you think?

We have `guarantee` which will catch the bug. However ASLR might make difficult to reproduce the bug.
I think it is not critical for 8 and 11. We are working to make JVM performance with 240M CodeCache similar to the performance with smaller CodeCache. This will decrease chances that people will use small CodeCache. We will be backporting enhancement to 17. 
It looks to me, risks are mitigated in old releases. There is no need for backports.

-------------

PR: https://git.openjdk.org/jdk/pull/9235

From coleenp at openjdk.org  Thu Jun 23 12:30:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 12:30:44 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split [v2]
In-Reply-To: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
Message-ID: <OzVZtuvorEPWlqOIti5-QWDTpfh0uy60QK1kyIyBIHo=.04544283-e9e3-46a4-bbdc-d94cabf06e1b@github.com>

> Remove extra include directives.  Tested with GHA.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant include

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9252/files
  - new: https://git.openjdk.org/jdk/pull/9252/files/f3e109c8..1a249ab4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9252&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9252&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9252.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9252/head:pull/9252

PR: https://git.openjdk.org/jdk/pull/9252

From coleenp at openjdk.org  Thu Jun 23 12:30:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 12:30:44 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split [v2]
In-Reply-To: <OtEIfurQwLDB_rWFrsyHIWxdL1rLJLnL62i5k2fApN4=.df78d00f-8f62-4c2e-b426-2c94ea336dd3@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
 <OtEIfurQwLDB_rWFrsyHIWxdL1rLJLnL62i5k2fApN4=.df78d00f-8f62-4c2e-b426-2c94ea336dd3@github.com>
Message-ID: <audt16pm3SUip4w-8_FgJ0iKUjNZpHYmBrZbU_oQXnw=.60e21ab0-979e-4f99-a8a6-8ba92df63d34@github.com>

On Thu, 23 Jun 2022 06:28:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove redundant include
>
> src/hotspot/cpu/zero/stack_zero.cpp line 32:
> 
>> 30: #include "runtime/javaThread.inline.hpp"
>> 31: #include "stack_zero.hpp"
>> 32: #include "stack_zero.inline.hpp"
> 
> Existing, but it is redundant to include the .hpp and the .inline.hpp file as the later always includes the former.

You're right.  I touched that line but didn't even see it.  I confirmed stack_zero.inline.hpp includes stack_zero.hpp, so removed the latter from stack_zero.cpp.  We'll let GHA confirm.

-------------

PR: https://git.openjdk.org/jdk/pull/9252

From stefank at openjdk.org  Thu Jun 23 13:39:43 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Jun 2022 13:39:43 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v9]
In-Reply-To: <tlRyBkKTZl0A4WdaGPltKinuEdtqC7TzxWARmcE293k=.8657673b-3cd2-47c3-af4b-4fae7ea35fba@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <tlRyBkKTZl0A4WdaGPltKinuEdtqC7TzxWARmcE293k=.8657673b-3cd2-47c3-af4b-4fae7ea35fba@github.com>
Message-ID: <JPH-R46xb1py_YVeYAM6vnpwb8029FvN-sSp5V_jYm4=.7168cdb3-c6c3-4aa6-8818-b352d1109658@github.com>

On Wed, 22 Jun 2022 22:32:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more missing header

Marked as reviewed by stefank (Reviewer).

Marked as reviewed by stefank (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From rpressler at openjdk.org  Thu Jun 23 15:00:46 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Thu, 23 Jun 2022 15:00:46 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v3]
In-Reply-To: <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>
Message-ID: <VkoX1b78eaLSoKbnECJEghwpYmhWJChIXOehfMkm1lg=.4869ce51-7583-4f5b-90a4-181b725fac6c@github.com>

On Thu, 23 Jun 2022 07:09:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
>> 
>> This is the relevant statement from the "Local Variable" section:
>> 
>> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
>> `
>> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
>> 
>> 
>> open/src/hotspot/share/runtime/vframe.cpp:300
>> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
>> 
>> Also, this is an analysis from Ron:
>> 
>> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
>> 
>> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
>> 
>> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
>> 
>> 
>> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
>> 
>> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
>> 
>> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - resolved 8286580 review comments; problem-listed test GetSetLocalTest under  8286836
>  - Merge branch 'master' into br2
>  - remove _depth == 0 clause from sanity check assert
>  - 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames

Marked as reviewed by rpressler (Author).

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From cjplummer at openjdk.org  Thu Jun 23 15:38:08 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jun 2022 15:38:08 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v3]
In-Reply-To: <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>
Message-ID: <taUdIxkuSct1vyb8kqJry-0ucdaB5D6eGIC8_Z9Gaj4=.97cfb327-122d-4365-abf9-095e3b79cc68@github.com>

On Thu, 23 Jun 2022 07:09:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
>> 
>> This is the relevant statement from the "Local Variable" section:
>> 
>> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
>> `
>> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
>> 
>> 
>> open/src/hotspot/share/runtime/vframe.cpp:300
>> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
>> 
>> Also, this is an analysis from Ron:
>> 
>> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
>> 
>> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
>> 
>> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
>> 
>> 
>> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
>> 
>> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
>> 
>> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - resolved 8286580 review comments; problem-listed test GetSetLocalTest under  8286836
>  - Merge branch 'master' into br2
>  - remove _depth == 0 clause from sanity check assert
>  - 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames

src/hotspot/share/prims/jvmtiImpl.cpp line 654:

> 652:       // frame at this point, because we aren't truly in the callee yet.
> 653:       // fr.is_heap_frame() is impossible if a continuation is at a single step or breakpoint.
> 654:       // In such cases the top frames can't be frozen because of an agent callback frame.

"frames" should be "frame".  I don't understand the agent callback frame reference.

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From duke at openjdk.org  Thu Jun 23 16:06:53 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Thu, 23 Jun 2022 16:06:53 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <GmiagvcE-NRRr4B-ZkOmhdhDQWC5fM37-cb4W2RdmRQ=.d3f078d7-bb86-41e9-88f0-086557a9db77@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

Cheers. Feel free to sponsor this.

-------------

PR: https://git.openjdk.org/jdk/pull/8992

From sspitsyn at openjdk.org  Thu Jun 23 16:13:58 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 16:13:58 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v4]
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <3Kuq7JLJVqFsjRwevwJ3awgWRfZOUmJVhozji1Oju5A=.b51669c0-cab7-4bb2-87d3-e3cba1b09425@github.com>

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  8286580 review: remove unneeded sentence in the comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/42/files
  - new: https://git.openjdk.org/jdk19/pull/42/files/ca7c3b3a..4c63a264

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=42&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=42&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/42.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/42/head:pull/42

PR: https://git.openjdk.org/jdk19/pull/42

From sspitsyn at openjdk.org  Thu Jun 23 16:14:03 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 16:14:03 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v3]
In-Reply-To: <taUdIxkuSct1vyb8kqJry-0ucdaB5D6eGIC8_Z9Gaj4=.97cfb327-122d-4365-abf9-095e3b79cc68@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <fS8f6qe4ZC7sO7wbLqUC-0_2FwuDngL7EnrLgq1m4fw=.45b55479-3dd7-400a-9f08-07d922695867@github.com>
 <taUdIxkuSct1vyb8kqJry-0ucdaB5D6eGIC8_Z9Gaj4=.97cfb327-122d-4365-abf9-095e3b79cc68@github.com>
Message-ID: <tpAWgRWQn3TRGdmYaMZxnqJFzi8WeuQZHUtOqJFnvlg=.c72bf00b-fccd-4789-bd2f-17a79fdc66a0@github.com>

On Thu, 23 Jun 2022 15:34:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - resolved 8286580 review comments; problem-listed test GetSetLocalTest under  8286836
>>  - Merge branch 'master' into br2
>>  - remove _depth == 0 clause from sanity check assert
>>  - 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 654:
> 
>> 652:       // frame at this point, because we aren't truly in the callee yet.
>> 653:       // fr.is_heap_frame() is impossible if a continuation is at a single step or breakpoint.
>> 654:       // In such cases the top frames can't be frozen because of an agent callback frame.
> 
> "frames" should be "frame".  I don't understand the agent callback frame reference.

Removed this sentence as unneeded.

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From cjplummer at openjdk.org  Thu Jun 23 16:18:42 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jun 2022 16:18:42 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v4]
In-Reply-To: <3Kuq7JLJVqFsjRwevwJ3awgWRfZOUmJVhozji1Oju5A=.b51669c0-cab7-4bb2-87d3-e3cba1b09425@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <3Kuq7JLJVqFsjRwevwJ3awgWRfZOUmJVhozji1Oju5A=.b51669c0-cab7-4bb2-87d3-e3cba1b09425@github.com>
Message-ID: <zhvgtLXneNmI2RA98NVUt-XqxTLm_ZZa9SIB6yaroSo=.2d4ffcc3-f55d-451c-8835-e98cabaef390@github.com>

On Thu, 23 Jun 2022 16:13:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
>> 
>> This is the relevant statement from the "Local Variable" section:
>> 
>> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
>> `
>> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
>> 
>> 
>> open/src/hotspot/share/runtime/vframe.cpp:300
>> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
>> 
>> Also, this is an analysis from Ron:
>> 
>> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
>> 
>> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
>> 
>> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
>> 
>> 
>> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
>> 
>> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
>> 
>> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286580 review: remove unneeded sentence in the comment

Marked as reviewed by cjplummer (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From dcubed at openjdk.org  Thu Jun 23 16:22:15 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 23 Jun 2022 16:22:15 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split [v2]
In-Reply-To: <OzVZtuvorEPWlqOIti5-QWDTpfh0uy60QK1kyIyBIHo=.04544283-e9e3-46a4-bbdc-d94cabf06e1b@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
 <OzVZtuvorEPWlqOIti5-QWDTpfh0uy60QK1kyIyBIHo=.04544283-e9e3-46a4-bbdc-d94cabf06e1b@github.com>
Message-ID: <pXAp9IXlB73F_DKRGGpQRHfEf89uyb3SJBMeixOaZP4=.6f04ceed-ce7f-43b9-a1bb-c858c326647f@github.com>

On Thu, 23 Jun 2022 12:30:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove extra include directives.  Tested with GHA.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant include

Thumbs up. Thanks for taking care of my late comments.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9252

From coleenp at openjdk.org  Thu Jun 23 16:22:16 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 16:22:16 GMT
Subject: RFR: 8289006: Cleanup from thread.hpp split [v2]
In-Reply-To: <OzVZtuvorEPWlqOIti5-QWDTpfh0uy60QK1kyIyBIHo=.04544283-e9e3-46a4-bbdc-d94cabf06e1b@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
 <OzVZtuvorEPWlqOIti5-QWDTpfh0uy60QK1kyIyBIHo=.04544283-e9e3-46a4-bbdc-d94cabf06e1b@github.com>
Message-ID: <aa3aWZsbHnWS2FOQujR3Oil9vJgA3-vh62GPhgdoj_Q=.db6adba8-4d5a-418c-b620-967ec3c5faba@github.com>

On Thu, 23 Jun 2022 12:30:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove extra include directives.  Tested with GHA.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant include

Thanks Dan for the comments, and David for reviewing.  Pushing as trivial.

-------------

PR: https://git.openjdk.org/jdk/pull/9252

From coleenp at openjdk.org  Thu Jun 23 16:24:57 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 16:24:57 GMT
Subject: Integrated: 8289006: Cleanup from thread.hpp split
In-Reply-To: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
References: <PxGIk5cmmssQBONP-u_JB4yh5SeezQWAB9GwfbRXIN4=.c54768a1-a9a4-4afe-9390-42bbb0e7849a@github.com>
Message-ID: <fLdYaUMn7p-pdt3iJlvdN-noghrNwXSMpVGUnVOrdo0=.07251322-cfc5-460c-9ea3-c198c96ec5ca@github.com>

On Wed, 22 Jun 2022 22:00:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove extra include directives.  Tested with GHA.

This pull request has now been integrated.

Changeset: b206d2d1
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b206d2d14937bf8cfebb629888a09311275ac0db
Stats:     6 lines in 2 files changed: 1 ins; 4 del; 1 mod

8289006: Cleanup from thread.hpp split

Reviewed-by: dholmes, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/9252

From sspitsyn at openjdk.org  Thu Jun 23 16:25:43 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 16:25:43 GMT
Subject: Integrated: 8286580: serviceability/jvmti/vthread/GetSetLocalTest
 failed with assert: Not supported for heap frames
In-Reply-To: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
Message-ID: <20cqImTN6Iq_X6xVj7ZZV6oS8vV_VBdZERAatB4vMTg=.1f9e510c-d2fe-48aa-b51d-cd240d16b549@github.com>

On Sat, 18 Jun 2022 03:59:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
> 
> This is the relevant statement from the "Local Variable" section:
> 
> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
> `
> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
> 
> 
> open/src/hotspot/share/runtime/vframe.cpp:300
> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
> 
> Also, this is an analysis from Ron:
> 
> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
> 
> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
> 
> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
> 
> 
> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
> 
> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
> 
> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.

This pull request has now been integrated.

Changeset: 4c9ea7e6
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/4c9ea7e66aaf99f42ee2df0b17c6586f57019a19
Stats:     44 lines in 4 files changed: 23 ins; 5 del; 16 mod

8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames

Reviewed-by: lmesnik, rpressler, cjplummer

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From coleenp at openjdk.org  Thu Jun 23 16:34:58 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 16:34:58 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v9]
In-Reply-To: <tlRyBkKTZl0A4WdaGPltKinuEdtqC7TzxWARmcE293k=.8657673b-3cd2-47c3-af4b-4fae7ea35fba@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <tlRyBkKTZl0A4WdaGPltKinuEdtqC7TzxWARmcE293k=.8657673b-3cd2-47c3-af4b-4fae7ea35fba@github.com>
Message-ID: <hCQfKZ7Ur08fHskXwFfgVY_1Va-lwZvQvdNpLg2VMZA=.332fb07f-88c2-46e3-a022-14631ae34088@github.com>

On Wed, 22 Jun 2022 22:32:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
>> 
>> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
>> 
>> - jdk_internal_vm_ContinuationScope
>> - jdk_internal_vm_Continuation
>> - jdk_internal_vm_StackChunk
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more missing header

Marked as reviewed by coleenp (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From sspitsyn at openjdk.org  Thu Jun 23 21:09:49 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 23 Jun 2022 21:09:49 GMT
Subject: RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed
 with assert: Not supported for heap frames [v4]
In-Reply-To: <3Kuq7JLJVqFsjRwevwJ3awgWRfZOUmJVhozji1Oju5A=.b51669c0-cab7-4bb2-87d3-e3cba1b09425@github.com>
References: <LnZzlVbx8CGo_ttnDhTCNbmsT87JVfSA5b0cMtCGRFY=.27abdeda-7244-4e73-bb51-4d8dc9f12068@github.com>
 <3Kuq7JLJVqFsjRwevwJ3awgWRfZOUmJVhozji1Oju5A=.b51669c0-cab7-4bb2-87d3-e3cba1b09425@github.com>
Message-ID: <PYa7Gu4bV2N1KEr7rTsuz79DbgdI5uQquycLFDBPap4=.9969c5ed-5183-42ad-b05e-9b163ef2c95f@github.com>

On Thu, 23 Jun 2022 16:13:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI SetLocalXXX requires the target virtual thread suspended at a breakpoint or single step event.
>> 
>> This is the relevant statement from the "Local Variable" section:
>> 
>> `The SetLocalXXX functions may be used to set the value of a local variable in the topmost frame of a virtual thread suspended at a breakpoint or single step event.
>> `
>> This fix is to return the JVMTI_ERROR_OPAQUE_FRAME in cases when the target thread is not at a breakpoint or single step event. In this case the assert described in the bug report is avoided:
>> 
>> 
>> open/src/hotspot/share/runtime/vframe.cpp:300
>> # assert(stack_chunk() == __null) failed: Not supported for heap frames 
>> 
>> Also, this is an analysis from Ron:
>> 
>> The problem occurs because the thread is suspended at a safepoint poll on return in the oldest thawed frame. The safepoint happens after the frame is popped but before it returns to the return barrier, thawing the caller (and so the stack looks as if we're in enterSpecial). In that case the virtual thread's topmost frame is still frozen on the heap, even though it is mounted.
>> 
>> However, the spec says that a set local operation should succeed for the topmost frame of a mounted virtual thread only if the thread is suspended *at a breakpoint or a single-step event*, and I don't think we can stop at that safepoint in that case.
>> 
>> If so, the fix is simple: if we're trying to set, even if the virtual thread is mounted and the depth is zero, if the frame is a heap frame, we should return an OPAQUE_FRAME error. The test should be changed as well to accept such an error if the thread is suspended not at a breakpoint/single-step. 
>> 
>> 
>> Changes `GetSetLocalTest` test are taken from the repo-loom repository. It was an update from Leonid which is needed to reproduce this problem.
>> 
>> The fix was tested with thousands of runs of the `GetSetLocalTest` on Linux, Windows and MacOs.
>> 
>> Will also submit nsk.jvmti and nsk.jdi test runs on mach5.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286580 review: remove unneeded sentence in the comment

Ron and Chris, thank you for reviews!

-------------

PR: https://git.openjdk.org/jdk19/pull/42

From coleenp at openjdk.org  Thu Jun 23 21:28:45 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 23 Jun 2022 21:28:45 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
In-Reply-To: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
References: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
Message-ID: <JoCothe8s5KcYX59IikB4Q7M1gpXNTMdN65cXgptTWA=.a8873eb6-5892-4bf3-a7f0-b366ab3e6d54@github.com>

On Mon, 20 Jun 2022 17:58:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure:
> 
> 
> In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29,
>                  from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28,
>                  from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34:
> In function 'const void* memchr(const void*, int, size_t)',
>     inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32,
>     inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6,
>     inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19:

Seems fine.

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/49

From iklam at openjdk.org  Fri Jun 24 00:16:21 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 00:16:21 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v10]
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <c7u_gp4t6XsNZa8a6yFC63E5iqwZEEiDAHes-fNVOno=.fd844b9c-4720-429f-bd87-733f56053925@github.com>

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into 8288623-move-continuation-out-of-javaClasses-hpp
 - one more missing header
 - fixed GHA build failures
 - added missing javaClasses.inline.hpp after merge with javaThread.hpp split
 - Merge branch 'master' into 8288623-move-continuation-out-of-javaClasses-hpp
 - Review comments
 - moved to runtime/continuationJavaClasses.hpp
 - @stefank review comments
 - fixed include guard macro and copyright year
 - added missing includes that were hidden by previously unnedded includes
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c8cc94a3...cd063427

-------------

Changes: https://git.openjdk.org/jdk/pull/9191/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9191&range=09
  Stats: 1064 lines in 25 files changed: 602 ins; 447 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9191.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9191/head:pull/9191

PR: https://git.openjdk.org/jdk/pull/9191

From kbarrett at openjdk.org  Fri Jun 24 00:18:52 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 24 Jun 2022 00:18:52 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]
In-Reply-To: <rXuJHIXH8JkmrcO5uB2vrI5Uwl8-wiW24NB7JBl6oGI=.a0d17213-d669-4487-9bcb-c82697664052@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <fhxL1VQphAya_pTHlUwQFjJvnFOBqi3yFl_mdPXHRRg=.9a7a9c43-0d21-42a1-9fef-49f2cda8e9fc@github.com>
 <mQQfJ5VE0sRuuD1vF3WuheItcIT6q9E3o11e_XMwqaE=.8bf8c992-a92e-4e77-8f5b-3699354da233@github.com>
 <X_yKACFG-77rTfSDLsO4HVp_8pVoUYE35x-LjpD4Uqg=.bae211c2-8454-4659-8724-19d0cd8bb393@github.com>
 <S_xUtV-sDyAsxqzQMqej7iFxZWZCPsUdNxznfJFiZ0w=.d2c3b9af-6bcf-4c76-bfff-42a19549bc66@github.com>
 <rXuJHIXH8JkmrcO5uB2vrI5Uwl8-wiW24NB7JBl6oGI=.a0d17213-d669-4487-9bcb-c82697664052@github.com>
Message-ID: <63A3vwzgxkFAtr--cfRniuGur2yTip7iPfX_y3Z4tsU=.15537746-5e1b-4a70-8dd8-aa128dbf7d50@github.com>

On Fri, 29 Apr 2022 11:39:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The `_reference_type` used to be initialized correctly in most cases, but
>> needed fixing up for a few cases during bootstrapping. With this change it is
>> *never* initialized correctly for Reference subtypes and always needs an
>> initialization kludge for them. That's not an improvement.
>
> `_reference_type` always gets the correct value after the constructor is run. The member initializer list just follows the convention of having all fields set. One could move this field inside the constructor body to ensure this field is set only once.

> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file.

The mechanism used to compute the correct reftype is purely derived from the
parser, and to me looks like "parsing". So I think it would be better placed
with the parser. And that would also remove the need for the two-step
initialization of the InstanceKlass member.

With that in mind, I think the file scoped function determine_reference_type
in instanceRefKlass.cpp should instead be an ordinary public member function
`ClassFileParser::reference_type() const` (with appropriate adjustment of it's
implementation), called by the InstanceKlass constructor to initialize
`_reference_type`.

Associated with that are some other changes:
- The new InstanceRefKlass::set_reference_type is no longer needed.
- The new ClassFileParser::super_reference_type and
ClassFileParser::is_java_lang_ref_Reference_subclass don't need to be public.
(Assuming they exist at all after adjustment of ClassFileParser::reference_type.)

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From iklam at openjdk.org  Fri Jun 24 04:33:12 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 04:33:12 GMT
Subject: RFR: 8288623: Move Continuation classes out of javaClasses.hpp
 [v3]
In-Reply-To: <DKTBMylz4j__VRfHkVdU_6VN1AagkOUovnRHa7_xBL0=.69ce82e8-5c82-4417-b6dd-dc7c0187b773@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
 <YTpgH8KqAeXKy7LfaSeiq4pFyyjLvP7jtcTuxd12Qb0=.5435dfb0-0ea0-4710-bd30-35668cd55956@github.com>
 <DKTBMylz4j__VRfHkVdU_6VN1AagkOUovnRHa7_xBL0=.69ce82e8-5c82-4417-b6dd-dc7c0187b773@github.com>
Message-ID: <L3jlxQ4-yLqhD14nj1RA_c8GEXdEL5ZCZqdJkawj92U=.e0bac14d-9dd0-47de-b994-6759a2bb145a@github.com>

On Fri, 17 Jun 2022 20:18:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed include guard macro and copyright year
>
> I've talked to Ioi and Coleen about whether `javaClasses` or `continuations` should be considered as the most relevant subsystem. Their take is that `continuations` is. I'm warming up to that thought, but I think I'd then would prefer if continuationsJavaClasses.hpp etc. get moved to where the other continuation files are, in the runtime/ directory.

Thanks to @stefank and @coleenp for the review.

- Passes our CI tier1 and build-tier5.
- GHA linux-x86 errors are unrelated to my changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From iklam at openjdk.org  Fri Jun 24 04:33:13 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 04:33:13 GMT
Subject: Integrated: 8288623: Move Continuation classes out of javaClasses.hpp
In-Reply-To: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
References: <GLxbNHujcIpj2Bwt-gC9d8eqIr8cwDT7SqjlIrRTsR8=.8a3f86d7-64cb-4a9e-959e-0914dc88bbdc@github.com>
Message-ID: <iaygA2rsnJJpHKhwfzgutuRkavVpGxDnn8iZ14KaBb0=.03dbe885-cfe0-4c6f-88fe-8cfb27773029@github.com>

On Thu, 16 Jun 2022 19:12:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> javaClasses.hpp is getting too big - it contains the C++ representation of over 50 Java classes.
> 
> The RFE moves the following classes into a new file, continuationJavaClasses.hpp. The naming follows the same pattern as the existing header share/jvmci/jvmciJavaClasses.hpp.
> 
> - jdk_internal_vm_ContinuationScope
> - jdk_internal_vm_Continuation
> - jdk_internal_vm_StackChunk

This pull request has now been integrated.

Changeset: 64782a75
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64782a7524038380c0e8b61cc74102463e997850
Stats:     1064 lines in 25 files changed: 602 ins; 447 del; 15 mod

8288623: Move Continuation classes out of javaClasses.hpp

Reviewed-by: stefank, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/9191

From duke at openjdk.org  Fri Jun 24 05:04:49 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Fri, 24 Jun 2022 05:04:49 GMT
Subject: Integrated: 8287281: adjust guarantee in Handshake::execute for the
 case of target thread being current
In-Reply-To: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
Message-ID: <GdU4Kj8VIP54UYZRV10AH95remutc_8lNZ3ufGso3MA=.a5e2b95a-c52e-4e01-9444-c2725cffdda5@github.com>

On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

> Please review this PR for fixing JDK-8287281.
> 
> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
> 
> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
> 
> 
> Passes tier1. Running tier2-5.

This pull request has now been integrated.

Changeset: 9dc9a64f
Author:    Johan Sj?l?n <johan.sjolen at oracle.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9dc9a64fa453d8afc90871e9663a0ccc46212f64
Stats:     29 lines in 3 files changed: 7 ins; 13 del; 9 mod

8287281: adjust guarantee in Handshake::execute for the case of target thread being current

Reviewed-by: rehn, pchilanomate, dholmes, dcubed

-------------

PR: https://git.openjdk.org/jdk/pull/8992

From iklam at openjdk.org  Fri Jun 24 05:50:05 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 05:50:05 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom [v3]
In-Reply-To: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
Message-ID: <TSpr1m4A3xx-Zvq0V9u3g7hWRQ7ot_SWMvb4c624ZbM=.1aec8a64-91c4-472f-b1cb-9ebe9308ab70@github.com>

> Some header files introduced in loom has unnecessary #includes. 
> 
> Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - fixed build; remove unnecessary include
 - Merge branch 'master' of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!InBSZkBKnpAGxjn08D8v6X1v3UCzO-bNQG1nlcIB55IT02B5vaiPmlwp7eXSFpHjaviSfs0Rud3dj8WnEujP$  into 8288935-fix-loom-excessive-includes
 - Merge branch 'master' into 8288935-fix-loom-excessive-includes
 - @stefank comments
 - fixed GHA
 - step2
 - temp

-------------

Changes: https://git.openjdk.org/jdk/pull/9231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9231&range=02
  Stats: 94 lines in 12 files changed: 48 ins; 42 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9231.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9231/head:pull/9231

PR: https://git.openjdk.org/jdk/pull/9231

From shade at openjdk.org  Fri Jun 24 07:49:58 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jun 2022 07:49:58 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
In-Reply-To: <JoCothe8s5KcYX59IikB4Q7M1gpXNTMdN65cXgptTWA=.a8873eb6-5892-4bf3-a7f0-b366ab3e6d54@github.com>
References: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
 <JoCothe8s5KcYX59IikB4Q7M1gpXNTMdN65cXgptTWA=.a8873eb6-5892-4bf3-a7f0-b366ab3e6d54@github.com>
Message-ID: <aNC_rRr69J2pPeTY73YovrEUxKO1Yva31XvbAnNzoDY=.308a2ec6-6c3f-4139-80bc-590787ef624f@github.com>

On Thu, 23 Jun 2022 21:25:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Seems fine.

Thanks! @kimbarrett, want to take a look as well?

-------------

PR: https://git.openjdk.org/jdk19/pull/49

From rpressler at openjdk.org  Fri Jun 24 09:42:06 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Fri, 24 Jun 2022 09:42:06 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing
Message-ID: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>

Please review the following bug fix:

`Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.

Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.

This change does three things:

1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
3. In interp_only_mode, the c2i stub will not patch the callsite.

This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128


Passes tiers 1-4 and Loom tiers 1-5.

-------------

Commit messages:
 - fix
 - Remove outdated comment
 - Unexclude test

Changes: https://git.openjdk.org/jdk19/pull/66/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288949
  Stats: 55 lines in 9 files changed: 48 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/66/head:pull/66

PR: https://git.openjdk.org/jdk19/pull/66

From ayang at openjdk.org  Fri Jun 24 12:09:08 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 24 Jun 2022 12:09:08 GMT
Subject: RFR: 8289138: G1: Remove redundant is-marking-active checks in C1
 barrier
Message-ID: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>

Simple change of removing a redundant check in C1 barrier code.

Test: tier1-3

-------------

Commit messages:
 - g1-c1-remove-mark-check

Changes: https://git.openjdk.org/jdk/pull/9274/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9274&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289138
  Stats: 51 lines in 6 files changed: 0 ins; 51 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9274.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9274/head:pull/9274

PR: https://git.openjdk.org/jdk/pull/9274

From duke at openjdk.org  Fri Jun 24 12:29:54 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Fri, 24 Jun 2022 12:29:54 GMT
Subject: RFR: 8288992: AArch64: CMN should be handled the same way as CMP
In-Reply-To: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
References: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
Message-ID: <Dz4jASNpFad11he8AJDrzU86JChl6pmqxUARj84CF8Q=.4f4375ac-d311-41f2-8122-48dfe11a770a@github.com>

On Wed, 22 Jun 2022 17:03:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

> At present, `cmp(r8, -1)` fails at compile time, but `cmn(r8, -1)` fails at runtime. We should fix cmn() to be the same as `cmp()`. 
> 
> After this change, it's much less likely that we'll be surprised by immediate overflows in `cmn()`.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 200:

> 198:   inline void cmp(Register Rd, unsigned imm) = delete;
> 199: 
> 200:   template<class T>

Why do we need it to be a template?

-------------

PR: https://git.openjdk.org/jdk/pull/9246

From aph at openjdk.org  Fri Jun 24 13:24:48 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 24 Jun 2022 13:24:48 GMT
Subject: RFR: 8288992: AArch64: CMN should be handled the same way as CMP
In-Reply-To: <Dz4jASNpFad11he8AJDrzU86JChl6pmqxUARj84CF8Q=.4f4375ac-d311-41f2-8122-48dfe11a770a@github.com>
References: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
 <Dz4jASNpFad11he8AJDrzU86JChl6pmqxUARj84CF8Q=.4f4375ac-d311-41f2-8122-48dfe11a770a@github.com>
Message-ID: <nDA8bQIaSWR7p-U8tVJMTlkp6CKz1N9olibU2_CTfqI=.d943040e-f850-4d1e-8a73-b9b95e2386ad@github.com>

On Fri, 24 Jun 2022 12:27:48 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

>> At present, `cmp(r8, -1)` fails at compile time, but `cmn(r8, -1)` fails at runtime. We should fix cmn() to be the same as `cmp()`. 
>> 
>> After this change, it's much less likely that we'll be surprised by immediate overflows in `cmn()`.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 200:
> 
>> 198:   inline void cmp(Register Rd, unsigned imm) = delete;
>> 199: 
>> 200:   template<class T>
> 
> Why do we need it to be a template?

If we made it `unsigned int`, we'd risk a 64-bit signed value (from C2, for example) being truncated before being passed to `addsw(Register Rd, Register Rn, uint64_t imm)`. As we now have a 64-bit-clean path through all this code, that would be a Bad Thing.

-------------

PR: https://git.openjdk.org/jdk/pull/9246

From iklam at openjdk.org  Fri Jun 24 14:46:51 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 14:46:51 GMT
Subject: RFR: 8288935: Remove excessive includes introduced in loom [v3]
In-Reply-To: <3Tyj243x9WvDw5n7o0uej4X2ytcAHxO1WGKWvWdNBo4=.5483cea9-d2ad-462d-9f3a-171d98b9b881@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
 <3Tyj243x9WvDw5n7o0uej4X2ytcAHxO1WGKWvWdNBo4=.5483cea9-d2ad-462d-9f3a-171d98b9b881@github.com>
Message-ID: <iHEWtf2uGQfT8c1PY3xtadbQBXmFdRQjeSDfewi0IlM=.250570d3-900d-46e1-9165-37c65d3560ee@github.com>

On Wed, 22 Jun 2022 09:14:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - fixed build; remove unnecessary include
>>  - Merge branch 'master' of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!Owi9k_hE36fhL80ruJmv-5tFPFxNatImWLXBvUHvTFMaYXYlnlwnUyG_BRzhmK9MKJmItM8bMSfl9sM0Bc38$  into 8288935-fix-loom-excessive-includes
>>  - Merge branch 'master' into 8288935-fix-loom-excessive-includes
>>  - @stefank comments
>>  - fixed GHA
>>  - step2
>>  - temp
>
> Looks good. I saw one obvious missing include.

Thanks to @stefank and @robehn for the review.

- Passes our CI tier1 and build-tier5.
- GHA linux-x86 errors are unrelated to my changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9231

From iklam at openjdk.org  Fri Jun 24 14:46:53 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 24 Jun 2022 14:46:53 GMT
Subject: Integrated: 8288935: Remove excessive includes introduced in loom
In-Reply-To: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
References: <xWiEgESLgRG7IW0bGr91uD5SUToq_9u5Z-ZYWCXWtN8=.8696dd11-e78d-47cb-ad48-b5d3b1e519ce@github.com>
Message-ID: <6uJY91thvyqKaN7-lQ_eK8tfSUhlOqLwteYoBXRtU-s=.e21304e9-c992-4e6e-926c-46005abd8062@github.com>

On Wed, 22 Jun 2022 05:55:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Some header files introduced in loom has unnecessary #includes. 
> 
> Also, some hpp files have complex inline functions that should be moved to either inline.hpp or cpp files.

This pull request has now been integrated.

Changeset: f67c5361
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f67c5361ccf5ac3cba9b88a3780afed2237ec19a
Stats:     94 lines in 12 files changed: 48 ins; 42 del; 4 mod

8288935: Remove excessive includes introduced in loom

Reviewed-by: rehn, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/9231

From dcubed at openjdk.org  Fri Jun 24 15:44:39 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 24 Jun 2022 15:44:39 GMT
Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case
 of target thread being current [v7]
In-Reply-To: <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
References: <dTjXcCEHqbJMzijM0NKT3XE7qR2kt1jEYA7lU_YtNKQ=.14907008-2983-4b89-9967-a75442500049@github.com>
 <aNsjeX2YaUFTLB_zTx0rXcZoOEP-a0D539LrGcHgzKM=.578cbb3c-a8f7-4e2c-a376-65ed5f886db2@github.com>
Message-ID: <_iCOYOBbDpntdRIq0b1MxKPDNEs8nUF9_tScAo6tVPc=.a1597b8b-1d79-45ea-a009-93537639dd69@github.com>

On Tue, 21 Jun 2022 19:22:43 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Please review this PR for fixing JDK-8287281.
>> 
>> If a thread is handshake safe we immediately execute the closure, instead of going through the regular Handshake process. 
>> 
>> Finally:  Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this.
>> 
>> 
>> Passes tier1. Running tier2-5.
>
> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check only for target == current

This PR has been backed out because it caused failures in Mach5 Tier[1-4].
See [JDK-8289129](https://bugs.openjdk.org/browse/JDK-8289129) [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current

-------------

PR: https://git.openjdk.org/jdk/pull/8992

From duke at openjdk.org  Fri Jun 24 16:14:42 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Fri, 24 Jun 2022 16:14:42 GMT
Subject: RFR: 8288992: AArch64: CMN should be handled the same way as CMP
In-Reply-To: <nDA8bQIaSWR7p-U8tVJMTlkp6CKz1N9olibU2_CTfqI=.d943040e-f850-4d1e-8a73-b9b95e2386ad@github.com>
References: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
 <Dz4jASNpFad11he8AJDrzU86JChl6pmqxUARj84CF8Q=.4f4375ac-d311-41f2-8122-48dfe11a770a@github.com>
 <nDA8bQIaSWR7p-U8tVJMTlkp6CKz1N9olibU2_CTfqI=.d943040e-f850-4d1e-8a73-b9b95e2386ad@github.com>
Message-ID: <MfwjRi98pFxUralVMxIRoTBfaVhepPOe6VsCx8MlJ9U=.12b2edc8-390f-48aa-83d4-41b0c265a018@github.com>

On Fri, 24 Jun 2022 13:21:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 200:
>> 
>>> 198:   inline void cmp(Register Rd, unsigned imm) = delete;
>>> 199: 
>>> 200:   template<class T>
>> 
>> Why do we need it to be a template?
>
> If we made it `unsigned int`, we'd risk a 64-bit signed value (from C2, for example) being truncated before being passed to `addsw(Register Rd, Register Rn, uint64_t imm)`. As we now have a 64-bit-clean path through all this code, that would be a Bad Thing.

Thank you for the explanation. I reread the code and found why I got confused.
`MacroAssembler::cmnw` call `addsw` which is defined by `WRAP(addsw, true)`. 
The macro expends to

void addsw(Register Rd, Register Rn, uint64_t imm) {
    wrap_adds_subs_imm_insn(Rd, Rn, imm, &Assembler::addsw, &Assembler::addsw, true);
}

void addsw(Register Rd, Register Rn, Register Rm, enum shift_kind kind, unsigned shift = 0) {
   Assembler::addsw(Rd, Rn, Rm, kind, shift);
}

void addsw(Register Rd, Register Rn, Register Rm) {
   Assembler::addsw(Rd, Rn, Rm);
}

void addsw(Register Rd, Register Rn, Register Rm, ext::operation option, int amount = 0) {
  Assembler::addsw(Rd, Rn, Rm, option, amount);
}


I've mixed it up with `Assembler::addsw(Register Rd, Register Rn, unsigned imm)`:

#define INSN(NAME, decode, negated)                                     \
  void NAME(Register Rd, Register Rn, unsigned imm, unsigned shift) {   \
    starti;                                                             \
    f(decode, 31, 29), f(0b10001, 28, 24), f(shift, 23, 22), f(imm, 21, 10); \
    zrf(Rd, 0), srf(Rn, 5);                                             \
  }                                                                     \
                                                                        \
  void NAME(Register Rd, Register Rn, unsigned imm) {                   \
    starti;                                                             \
    add_sub_immediate(current_insn, Rd, Rn, imm, decode, negated);      \
  }

  INSN(addsw, 0b001, 0b011);

-------------

PR: https://git.openjdk.org/jdk/pull/9246

From duke at openjdk.org  Fri Jun 24 16:14:41 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Fri, 24 Jun 2022 16:14:41 GMT
Subject: RFR: 8288992: AArch64: CMN should be handled the same way as CMP
In-Reply-To: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
References: <MXBYOgZXPflRYLVyhcda7bIcaQGmRGkGBpM0JkOU4Io=.5cbf5853-e42c-4f8b-825f-f99730396aad@github.com>
Message-ID: <rUH_w_nOsUwljZQ6Lycbum45J4eEgHaKfPjxAjw0i5s=.1b628629-b268-4373-9137-6f5ec679605e@github.com>

On Wed, 22 Jun 2022 17:03:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

> At present, `cmp(r8, -1)` fails at compile time, but `cmn(r8, -1)` fails at runtime. We should fix cmn() to be the same as `cmp()`. 
> 
> After this change, it's much less likely that we'll be surprised by immediate overflows in `cmn()`.

lgtm

-------------

Marked as reviewed by eastig at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/9246

From rpressler at openjdk.org  Fri Jun 24 20:42:56 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Fri, 24 Jun 2022 20:42:56 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing
In-Reply-To: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
Message-ID: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com>

On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> Please review the following bug fix:
> 
> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
> 
> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
> 
> This change does three things:
> 
> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
> 3. In interp_only_mode, the c2i stub will not patch the callsite.
> 
> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
> 
> 
> Passes tiers 1-4 and Loom tiers 1-5.

src/hotspot/share/code/compiledIC.cpp line 591:

> 589:   // Do not reset stub here:  It is too expensive to call find_stub.
> 590:   // Instead, rely on caller (nmethod::clear_inline_caches) to clear
> 591:   // both the call and its stub.

While at it, I noticed this comment, which appears to be out of date.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From dlong at openjdk.org  Sat Jun 25 00:45:41 2022
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Jun 2022 00:45:41 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing
In-Reply-To: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com>
Message-ID: <ZXLuSjs4CJTInmrEJqWn4_ekKVoBUIbw1ZeinA8LiN8=.abab0d21-9f45-40bf-a50a-9e060532ee34@github.com>

On Fri, 24 Jun 2022 20:39:08 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Please review the following bug fix:
>> 
>> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
>> 
>> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
>> 
>> This change does three things:
>> 
>> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
>> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
>> 3. In interp_only_mode, the c2i stub will not patch the callsite.
>> 
>> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
>> 
>> 
>> Passes tiers 1-4 and Loom tiers 1-5.
>
> src/hotspot/share/code/compiledIC.cpp line 591:
> 
>> 589:   // Do not reset stub here:  It is too expensive to call find_stub.
>> 590:   // Instead, rely on caller (nmethod::clear_inline_caches) to clear
>> 591:   // both the call and its stub.
> 
> While at it, I noticed this comment, which appears to be out of date.

I read that comment more as a warning, in case in the future someone wondered why we don't reset the stub here, and tried to add it.  So I would leave it.  I think it's still useful.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From dlong at openjdk.org  Sat Jun 25 01:17:57 2022
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Jun 2022 01:17:57 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing
In-Reply-To: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
Message-ID: <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>

On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> Please review the following bug fix:
> 
> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
> 
> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
> 
> This change does three things:
> 
> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
> 3. In interp_only_mode, the c2i stub will not patch the callsite.
> 
> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
> 
> 
> Passes tiers 1-4 and Loom tiers 1-5.

src/hotspot/share/code/compiledMethod.cpp line 464:

> 462:   while(iter.next()) {
> 463:     if (iter.type() == relocInfo::static_call_type) {
> 464:       iter.reloc()->clear_inline_cache();

This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode.  If this was being done at a safepoint then it would probably be OK.  However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351).

src/hotspot/share/runtime/mutexLocker.cpp line 287:

> 285:   def(JfieldIdCreation_lock        , PaddedMutex  , safepoint);
> 286: 
> 287:   def(CompiledIC_lock              , PaddedMutex  , nosafepoint-1);  // locks VtableStubs_lock, InlineCacheBuffer_lock

Please explain.  Is there another lock causing problems?

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From rpressler at openjdk.org  Sat Jun 25 01:23:47 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Sat, 25 Jun 2022 01:23:47 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
Message-ID: <xg0f-ywbZNX8N8b5kKIiMdTL-cu7_CElflEuEhiswrw=.986a3c9a-5c31-4a4f-8f50-bea344358577@github.com>

> Please review the following bug fix:
> 
> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
> 
> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
> 
> This change does three things:
> 
> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
> 3. In interp_only_mode, the c2i stub will not patch the callsite.
> 
> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
> 
> 
> Passes tiers 1-4 and Loom tiers 1-5.

Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Remove outdated comment"
  
  This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/66/files
  - new: https://git.openjdk.org/jdk19/pull/66/files/fe8fe94f..4680aed2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/66/head:pull/66

PR: https://git.openjdk.org/jdk19/pull/66

From dlong at openjdk.org  Sat Jun 25 01:23:49 2022
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Jun 2022 01:23:49 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing
In-Reply-To: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
Message-ID: <p6uiL9KfbzbuZwZYTbw-GYQCh1tFFqf_AGB5HQdsWLQ=.a4841557-8d9c-4adc-bcb7-7051681032c1@github.com>

On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

> Please review the following bug fix:
> 
> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
> 
> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
> 
> This change does three things:
> 
> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
> 3. In interp_only_mode, the c2i stub will not patch the callsite.
> 
> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
> 
> 
> Passes tiers 1-4 and Loom tiers 1-5.

The get_c2i_entry change seems safe enough, but the lock rank change and the code patching changes seem a little risky for jdk19.  I'm going to suggest some folks more familiar with handshakes, compiled ICs, and lock ranking to also look at this.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From rpressler at openjdk.org  Sat Jun 25 01:23:52 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Sat, 25 Jun 2022 01:23:52 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <ZXLuSjs4CJTInmrEJqWn4_ekKVoBUIbw1ZeinA8LiN8=.abab0d21-9f45-40bf-a50a-9e060532ee34@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com>
 <ZXLuSjs4CJTInmrEJqWn4_ekKVoBUIbw1ZeinA8LiN8=.abab0d21-9f45-40bf-a50a-9e060532ee34@github.com>
Message-ID: <waLB-91AgQfq0jmMwMhUw2kE1RtY0LEmPOeklbJNUbY=.f87c04bf-d9c1-416f-a7d9-87e0252b0e03@github.com>

On Sat, 25 Jun 2022 00:42:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/code/compiledIC.cpp line 591:
>> 
>>> 589:   return true;
>>> 590: }
>>> 591: 
>> 
>> While at it, I noticed this comment, which appears to be out of date.
>
> I read that comment more as a warning, in case in the future someone wondered why we don't reset the stub here, and tried to add it.  So I would leave it.  I think it's still useful.

ok, reverted.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From rpressler at openjdk.org  Sat Jun 25 01:23:53 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Sat, 25 Jun 2022 01:23:53 GMT
Subject: RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
Message-ID: <e-0FtfWQ8YGXGJwx_PKLDF6d_Q8eUqF8nJzOpbopE0g=.5cc756fe-375d-4d13-8d26-39b78d40e4e4@github.com>

On Sat, 25 Jun 2022 01:14:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Remove outdated comment"
>>   
>>   This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.
>
> src/hotspot/share/runtime/mutexLocker.cpp line 287:
> 
>> 285:   def(JfieldIdCreation_lock        , PaddedMutex  , safepoint);
>> 286: 
>> 287:   def(CompiledIC_lock              , PaddedMutex  , nosafepoint-1);  // locks VtableStubs_lock, InlineCacheBuffer_lock
> 
> Please explain.  Is there another lock causing problems?

The handshake lock, which is also nosafepoint.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From kbarrett at openjdk.org  Sat Jun 25 08:40:53 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 25 Jun 2022 08:40:53 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
In-Reply-To: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
References: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
Message-ID: <OV97_XBymteuXCSK-pNSQsfhyAyQQL12LPJAjcJCtUs=.09873964-cb95-457d-95ea-38d2135260e9@github.com>

On Mon, 20 Jun 2022 17:58:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure:
> 
> 
> In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35,
>                  from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29,
>                  from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28,
>                  from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34:
> In function 'const void* memchr(const void*, int, size_t)',
>     inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32,
>     inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41,
>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6,
>     inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19:

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/signature.cpp line 328:

> 326: 
> 327: PRAGMA_DIAG_PUSH
> 328: PRAGMA_STRINGOP_OVERREAD_IGNORED

Don't make this change.  The warning is indicating an actual problem with the code.  The while loop on line 338 may terminate with `end == limit` if the string consists of just a sequence of '[' and then ends.  If the loop ends for that reason, we later read `base[limit]`, invoking UB as limit is the length of base.  As a proof of concept, adding

if (end >= limit) return limit;

after the while loop makes the warning go away.  I have no idea what the correct thing to do for this might be.  Returning limit might be wrong; I just used that to verify this issue is the source of the warning.

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 60:

> 58: #if !defined(__clang_major__) && (__GNUC__ >= 8)
> 59: #define PRAGMA_STRINGOP_TRUNCATION_IGNORED PRAGMA_DISABLE_GCC_WARNING("-Wstringop-truncation")
> 60: #endif

Why was `PRAGMA_STRINGOP_TRUNCATION` moved?  Oh, I see, you are reordering based on version.  I'd rather all three of these `-Wstringop-xxx` were together, perhaps sorted alphabetically.  I don't see the use of a version ordering.  So my preference would be that this part of the change wasn't made.

-------------

PR: https://git.openjdk.org/jdk19/pull/49

From kbarrett at openjdk.org  Sat Jun 25 08:40:55 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 25 Jun 2022 08:40:55 GMT
Subject: RFR: 8288759: GCC 12 fails to compile signature.cpp due to
 -Wstringop-overread bug
In-Reply-To: <OV97_XBymteuXCSK-pNSQsfhyAyQQL12LPJAjcJCtUs=.09873964-cb95-457d-95ea-38d2135260e9@github.com>
References: <X2C0JhPAWWCyASFf5huMOmCnu9PRg64_M0aau-fV-5s=.002953e4-c1c6-4882-9510-3a3502bc6f38@github.com>
 <OV97_XBymteuXCSK-pNSQsfhyAyQQL12LPJAjcJCtUs=.09873964-cb95-457d-95ea-38d2135260e9@github.com>
Message-ID: <RvkNMBSV_rSasXIBsO8uEgMJSMIIk_J9J2JK0DoRqzU=.37027294-705a-43e5-b3dc-3c5bbb08dbda@github.com>

On Sat, 25 Jun 2022 07:31:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Trying to compile with GCC 12.1.1 (current Fedora Rawhide) yields this failure:
>> 
>> 
>> In file included from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions_gcc.hpp:35,
>>                  from /home/test/shipilev-jdk/src/hotspot/share/utilities/globalDefinitions.hpp:35,
>>                  from /home/test/shipilev-jdk/src/hotspot/share/memory/allocation.hpp:29,
>>                  from /home/test/shipilev-jdk/src/hotspot/share/classfile/classLoaderData.hpp:28,
>>                  from /home/test/shipilev-jdk/src/hotspot/share/precompiled/precompiled.hpp:34:
>> In function 'const void* memchr(const void*, int, size_t)',
>>     inlined from 'int SignatureStream::scan_type(BasicType)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:343:32,
>>     inlined from 'void SignatureStream::next()' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:373:19,
>>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:635:41,
>>     inlined from 'void SignatureIterator::do_parameters_on(T*) [with T = Fingerprinter]' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.hpp:629:6,
>>     inlined from 'void Fingerprinter::compute_fingerprint_and_return_type(bool)' at /home/test/shipilev-jdk/src/hotspot/share/runtime/signature.cpp:169:19:
>
> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 60:
> 
>> 58: #if !defined(__clang_major__) && (__GNUC__ >= 8)
>> 59: #define PRAGMA_STRINGOP_TRUNCATION_IGNORED PRAGMA_DISABLE_GCC_WARNING("-Wstringop-truncation")
>> 60: #endif
> 
> Why was `PRAGMA_STRINGOP_TRUNCATION` moved?  Oh, I see, you are reordering based on version.  I'd rather all three of these `-Wstringop-xxx` were together, perhaps sorted alphabetically.  I don't see the use of a version ordering.  So my preference would be that this part of the change wasn't made.

But note this part of the change shouldn't be done at all, per my comments elsewhere.

-------------

PR: https://git.openjdk.org/jdk19/pull/49

From eosterlund at openjdk.org  Mon Jun 27 08:29:31 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 27 Jun 2022 08:29:31 GMT
Subject: [jdk19] RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
Message-ID: <GYrVVZlnfskYUO3rjJjY4AhqDUVBWHcbdSQJROUR2MQ=.87f3b764-41df-4b0f-af75-d99e2b56a9f2@github.com>

On Sat, 25 Jun 2022 01:12:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Remove outdated comment"
>>   
>>   This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.
>
> src/hotspot/share/code/compiledMethod.cpp line 464:
> 
>> 462:   while(iter.next()) {
>> 463:     if (iter.type() == relocInfo::static_call_type) {
>> 464:       iter.reloc()->clear_inline_cache();
> 
> This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode.  If this was being done at a safepoint then it would probably be OK.  However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351).  Maybe this race is OK, as it seems no worse than the scenario described in the description where another thread resets the call site back to the optimized state.

The change is not guaranteed to be seen on a concurrent thread, until the next global handshake operation completes.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From rpressler at openjdk.org  Mon Jun 27 08:29:32 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Mon, 27 Jun 2022 08:29:32 GMT
Subject: [jdk19] RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <GYrVVZlnfskYUO3rjJjY4AhqDUVBWHcbdSQJROUR2MQ=.87f3b764-41df-4b0f-af75-d99e2b56a9f2@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
 <GYrVVZlnfskYUO3rjJjY4AhqDUVBWHcbdSQJROUR2MQ=.87f3b764-41df-4b0f-af75-d99e2b56a9f2@github.com>
Message-ID: <DL7730AFl0Nhc8gXfF8NNqZ5SauCGdjcyJGtqXjpTjg=.919851a5-ae27-45a2-a3ce-a5cb33637383@github.com>

On Mon, 27 Jun 2022 08:17:01 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/code/compiledMethod.cpp line 464:
>> 
>>> 462:   while(iter.next()) {
>>> 463:     if (iter.type() == relocInfo::static_call_type) {
>>> 464:       iter.reloc()->clear_inline_cache();
>> 
>> This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode.  If this was being done at a safepoint then it would probably be OK.  However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351).  Maybe this race is OK, as it seems no worse than the scenario described in the description where another thread resets the call site back to the optimized state.
>
> The change is not guaranteed to be seen on a concurrent thread, until the next global handshake operation completes.

If that concurrent thread is in interp_only_mode, it also would have done the same patching. And if it isn't, then it's okay for it not to see this, but if it does see it, it will re-patch to compiled in c2i, as in the description.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From tschatzl at openjdk.org  Mon Jun 27 08:41:27 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 27 Jun 2022 08:41:27 GMT
Subject: RFR: 8289138: G1: Remove redundant is-marking-active checks in C1
 barrier
In-Reply-To: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
References: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
Message-ID: <cpBfRKX0K-9A4A1jdGU1c1Y2gkhTpvNRer-DPY3FAFc=.57666646-80f8-49c7-bd88-0a99cd0e0a96@github.com>

On Fri, 24 Jun 2022 12:00:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant check in C1 barrier code.
> 
> Test: tier1-3

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9274

From jwilhelm at openjdk.org  Mon Jun 27 11:55:51 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 11:55:51 GMT
Subject: RFR: Merge jdk19
Message-ID: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge
 - 8289079: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 failed with "RuntimeException: Test failed"
 - 8247407: tools/jlink/plugins/CompressorPluginTest.java test failing
 - 8288983: broken link in com.sun.net.httpserver.SimpleFileServer
 - 8289044: ARM32: missing LIR_Assembler::cmove metadata type support
 - 8288120: VerifyError with JEP 405 pattern match
 - 8288528: broken links in java.desktop
 - 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE
 - 8287076: Document.normalizeDocument() produces different results
 - 8288589: Files.readString ignores encoding errors for UTF-16
 - ... and 2 more: https://git.openjdk.org/jdk/compare/7905788e...9579cc05

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9296/files
  Stats: 366 lines in 24 files changed: 274 ins; 41 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296

From stefank at openjdk.org  Mon Jun 27 14:17:40 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 27 Jun 2022 14:17:40 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]
In-Reply-To: <63A3vwzgxkFAtr--cfRniuGur2yTip7iPfX_y3Z4tsU=.15537746-5e1b-4a70-8dd8-aa128dbf7d50@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <fhxL1VQphAya_pTHlUwQFjJvnFOBqi3yFl_mdPXHRRg=.9a7a9c43-0d21-42a1-9fef-49f2cda8e9fc@github.com>
 <mQQfJ5VE0sRuuD1vF3WuheItcIT6q9E3o11e_XMwqaE=.8bf8c992-a92e-4e77-8f5b-3699354da233@github.com>
 <X_yKACFG-77rTfSDLsO4HVp_8pVoUYE35x-LjpD4Uqg=.bae211c2-8454-4659-8724-19d0cd8bb393@github.com>
 <S_xUtV-sDyAsxqzQMqej7iFxZWZCPsUdNxznfJFiZ0w=.d2c3b9af-6bcf-4c76-bfff-42a19549bc66@github.com>
 <rXuJHIXH8JkmrcO5uB2vrI5Uwl8-wiW24NB7JBl6oGI=.a0d17213-d669-4487-9bcb-c82697664052@github.com>
 <63A3vwzgxkFAtr--cfRniuGur2yTip7iPfX_y3Z4tsU=.15537746-5e1b-4a70-8dd8-aa128dbf7d50@github.com>
Message-ID: <fzJRB4-F4rnRS4HKvBT_lCcohb4FTJ0R1rTyqhe4NeA=.a291dce1-1a0f-4f54-a3ee-7f7a3b04f062@github.com>

On Fri, 24 Jun 2022 00:15:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> `_reference_type` always gets the correct value after the constructor is run. The member initializer list just follows the convention of having all fields set. One could move this field inside the constructor body to ensure this field is set only once.
>
>> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file.
> 
> The mechanism used to compute the correct reftype is purely derived from the
> parser, and to me looks like "parsing". So I think it would be better placed
> with the parser. And that would also remove the need for the two-step
> initialization of the InstanceKlass member.
> 
> With that in mind, I think the file scoped function determine_reference_type
> in instanceRefKlass.cpp should instead be an ordinary public member function
> `ClassFileParser::reference_type() const` (with appropriate adjustment of it's
> implementation), called by the InstanceKlass constructor to initialize
> `_reference_type`.
> 
> Associated with that are some other changes:
> - The new InstanceRefKlass::set_reference_type is no longer needed.
> - The new ClassFileParser::super_reference_type and
> ClassFileParser::is_java_lang_ref_Reference_subclass don't need to be public.
> (Assuming they exist at all after adjustment of ClassFileParser::reference_type.)

> The _reference_type used to be initialized correctly in most cases, but
needed fixing up for a few cases during bootstrapping. With this change it is
never initialized correctly for Reference subtypes and always needs an
initialization kludge for them. That's not an improvement.

I don't agree that this is a kludge. This is quite common in HotSpot, and the code is quite understandable. It's far better than the initialization kludge the code had before this patch.

I'd like to suggest that we go with the proposed patch, and consider the Kim's latest proposal as a follow-up RFE. That way we can make progress on this RFE, and then weigh the pros and cons of this suggestion separately.

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From stefank at openjdk.org  Mon Jun 27 14:29:40 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 27 Jun 2022 14:29:40 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]
In-Reply-To: <fzJRB4-F4rnRS4HKvBT_lCcohb4FTJ0R1rTyqhe4NeA=.a291dce1-1a0f-4f54-a3ee-7f7a3b04f062@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <fhxL1VQphAya_pTHlUwQFjJvnFOBqi3yFl_mdPXHRRg=.9a7a9c43-0d21-42a1-9fef-49f2cda8e9fc@github.com>
 <mQQfJ5VE0sRuuD1vF3WuheItcIT6q9E3o11e_XMwqaE=.8bf8c992-a92e-4e77-8f5b-3699354da233@github.com>
 <X_yKACFG-77rTfSDLsO4HVp_8pVoUYE35x-LjpD4Uqg=.bae211c2-8454-4659-8724-19d0cd8bb393@github.com>
 <S_xUtV-sDyAsxqzQMqej7iFxZWZCPsUdNxznfJFiZ0w=.d2c3b9af-6bcf-4c76-bfff-42a19549bc66@github.com>
 <rXuJHIXH8JkmrcO5uB2vrI5Uwl8-wiW24NB7JBl6oGI=.a0d17213-d669-4487-9bcb-c82697664052@github.com>
 <63A3vwzgxkFAtr--cfRniuGur2yTip7iPfX_y3Z4tsU=.15537746-5e1b-4a70-8dd8-aa128dbf7d50@github.com>
 <fzJRB4-F4rnRS4HKvBT_lCcohb4FTJ0R1rTyqhe4NeA=.a291dce1-1a0f-4f54-a3ee-7f7a3b04f062@github.com>
Message-ID: <p8demOQ6ceLAYT5LkVHyhuGkC-PHEOdmjopk_5KaGcg=.384f6b9a-3d3c-45c5-b885-0aafef3ce7e4@github.com>

On Mon, 27 Jun 2022 14:14:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> The current approach limits the knowledge of non-strong ref types to `instanceRefKlass` file.
>> 
>> The mechanism used to compute the correct reftype is purely derived from the
>> parser, and to me looks like "parsing". So I think it would be better placed
>> with the parser. And that would also remove the need for the two-step
>> initialization of the InstanceKlass member.
>> 
>> With that in mind, I think the file scoped function determine_reference_type
>> in instanceRefKlass.cpp should instead be an ordinary public member function
>> `ClassFileParser::reference_type() const` (with appropriate adjustment of it's
>> implementation), called by the InstanceKlass constructor to initialize
>> `_reference_type`.
>> 
>> Associated with that are some other changes:
>> - The new InstanceRefKlass::set_reference_type is no longer needed.
>> - The new ClassFileParser::super_reference_type and
>> ClassFileParser::is_java_lang_ref_Reference_subclass don't need to be public.
>> (Assuming they exist at all after adjustment of ClassFileParser::reference_type.)
>
>> The _reference_type used to be initialized correctly in most cases, but
> needed fixing up for a few cases during bootstrapping. With this change it is
> never initialized correctly for Reference subtypes and always needs an
> initialization kludge for them. That's not an improvement.
> 
> I don't agree that this is a kludge. This is quite common in HotSpot, and the code is quite understandable. It's far better than the initialization kludge the code had before this patch.
> 
> I'd like to suggest that we go with the proposed patch, and consider the Kim's latest proposal as a follow-up RFE. That way we can make progress on this RFE, and then weigh the pros and cons of this suggestion separately.

Talked to Albert. He's already created a patch for this, so I retract my objection to this blocking of the PR.

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From aph at openjdk.org  Mon Jun 27 14:51:05 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 27 Jun 2022 14:51:05 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter
Message-ID: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>

There are several places in the interpreter that could be improved.

1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

-------------

Commit messages:
 - 8288971: AArch64: Clean up stack and register handling in interpreter
 - 8288971: AArch64: Clean up stack and register handling in interpreter

Changes: https://git.openjdk.org/jdk/pull/9239/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288971
  Stats: 156 lines in 14 files changed: 67 ins; 36 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/9239.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9239/head:pull/9239

PR: https://git.openjdk.org/jdk/pull/9239

From coleenp at openjdk.org  Mon Jun 27 14:58:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 27 Jun 2022 14:58:47 GMT
Subject: [jdk19] RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <e-0FtfWQ8YGXGJwx_PKLDF6d_Q8eUqF8nJzOpbopE0g=.5cc756fe-375d-4d13-8d26-39b78d40e4e4@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <Wxxm-QUWqU8dEMcaLAJuAtRL9tzU4QkM7NjdVMhl8DU=.94dae3bb-5144-46ea-8437-169a64dc4d56@github.com>
 <e-0FtfWQ8YGXGJwx_PKLDF6d_Q8eUqF8nJzOpbopE0g=.5cc756fe-375d-4d13-8d26-39b78d40e4e4@github.com>
Message-ID: <eR22a2v4BAwzNGSQYgG2Fizjwd2XaXIkAL5_Y_MwWM4=.90d7f2d1-146e-4fe2-8da8-f5a7edcb6873@github.com>

On Sat, 25 Jun 2022 01:19:10 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 287:
>> 
>>> 285:   def(JfieldIdCreation_lock        , PaddedMutex  , safepoint);
>>> 286: 
>>> 287:   def(CompiledIC_lock              , PaddedMutex  , nosafepoint-1);  // locks VtableStubs_lock, InlineCacheBuffer_lock
>> 
>> Please explain.  Is there another lock causing problems?
>
> The handshake lock, which is also nosafepoint.

This should be ok, provided all the tests have been run.

It reduces the rank of other locks, but there's still room in the lock rank range (by 1), and there's an assert for that.
  // These locks have relative rankings, and inherit safepoint checking attributes from that rank.
  defl(InlineCacheBuffer_lock      , PaddedMutex  , CompiledIC_lock);
  defl(VtableStubs_lock            , PaddedMutex  , CompiledIC_lock);  // Also holds DumpTimeTable_lock
  defl(CodeCache_lock              , PaddedMonitor, VtableStubs_lock);
  defl(CompiledMethod_lock         , PaddedMutex  , CodeCache_lock);
  defl(CodeSweeper_lock            , PaddedMonitor, CompiledMethod_lock);

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From rehn at openjdk.org  Mon Jun 27 15:24:43 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 27 Jun 2022 15:24:43 GMT
Subject: [jdk19] RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <xg0f-ywbZNX8N8b5kKIiMdTL-cu7_CElflEuEhiswrw=.986a3c9a-5c31-4a4f-8f50-bea344358577@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <xg0f-ywbZNX8N8b5kKIiMdTL-cu7_CElflEuEhiswrw=.986a3c9a-5c31-4a4f-8f50-bea344358577@github.com>
Message-ID: <wv2NSC87P7IFoeiUuQiJ3WT-DIjItHgsX1YwI6LaAaM=.f58fdb2d-de8f-47f5-86c3-9607f9631bb6@github.com>

On Sat, 25 Jun 2022 01:23:47 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Please review the following bug fix:
>> 
>> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
>> 
>> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
>> 
>> This change does three things:
>> 
>> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
>> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
>> 3. In interp_only_mode, the c2i stub will not patch the callsite.
>> 
>> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
>> 
>> 
>> Passes tiers 1-4 and Loom tiers 1-5.
>
> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Remove outdated comment"
>   
>   This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.

Handshakes are per thread serialization points, so as Erik says, the thread going to interp mode will pick up the correct code, but other threads may or may not see it.
Lock rank change may be okay, to much code to trace just say yes for me.

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <QcElHQNvmhWdtuoJp8PQe_xbRrvU3U4EGBqA20EQnPw=.77ba96a7-3560-4cd8-b8ad-0aec9e1ac6ee@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 146 commits:

 - Merge
 - 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent
   
   Reviewed-by: ayang, cjplummer
 - 8289078: Make STARTTIME_ANY and STARTTIME_PROCESS_UNKNOWN fields static in ProcessHandleImpl
   
   Reviewed-by: jpai, rriggs, bpb, naoto, iris
 - 8289147: unify os::infinite_sleep on posix platforms
   
   Reviewed-by: mdoerr, kbarrett, dholmes
 - 8266670: Better modeling of access flags in core reflection
   
   Reviewed-by: mchung, rriggs, asotona
 - 8286395: Address possibly lossy conversions in java.security.jgss
   
   Reviewed-by: chegar
 - 8286389: Address possibly lossy conversions in jdk.crypto.ec
   
   Reviewed-by: chegar, xuelei
 - 8288130: compiler error with AP and explicit record accessor
   
   Reviewed-by: jlahoda
 - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java
   
   Reviewed-by: lmesnik, bpb
 - 8289098: clean up ported serviceability/jvmti tests
   
   Reviewed-by: kevinw, sspitsyn
 - ... and 136 more: https://git.openjdk.org/jdk/compare/7e13cdb7...9579cc05

-------------

Changes: https://git.openjdk.org/jdk/pull/9296/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9296&range=01
  Stats: 47784 lines in 1125 files changed: 22921 ins; 12915 del; 11948 mod
  Patch: https://git.openjdk.org/jdk/pull/9296.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9296/head:pull/9296

PR: https://git.openjdk.org/jdk/pull/9296

From jwilhelm at openjdk.org  Mon Jun 27 18:32:18 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Mon, 27 Jun 2022 18:32:18 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
References: <n1VhMSF5oSsjvJGJRyNq_A2SRT2wNUD6iAthaSZs46M=.f6815ed8-53de-47a9-8991-ab76fba7c23a@github.com>
Message-ID: <EOnXQGf1n2TS6psge4FEfSaSTM5kHMVXlCOMzBiffUw=.59ead9f8-4337-4c81-8b7b-55e735c78ac6@github.com>

On Mon, 27 Jun 2022 11:49:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: d4b040f4
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182
Stats:     366 lines in 24 files changed: 274 ins; 41 del; 51 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9296

From iklam at openjdk.org  Mon Jun 27 20:01:30 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 27 Jun 2022 20:01:30 GMT
Subject: RFR: 8289231: Move java_lang_VirtualThread to
 continuationJavaClasses.hpp
Message-ID: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>

This is a follow up to [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623). `java_lang_VirtualThread` is part of loom and should be move to continuationJavaClasses.hpp, which contains the accessors for the other java classes used by loom.

-------------

Commit messages:
 - 8289231: Move java_lang_VirtualThread to continuationJavaClasses.hpp

Changes: https://git.openjdk.org/jdk/pull/9298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289231
  Stats: 303 lines in 15 files changed: 154 ins; 147 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9298.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9298/head:pull/9298

PR: https://git.openjdk.org/jdk/pull/9298

From alanb at openjdk.org  Mon Jun 27 20:16:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 20:16:51 GMT
Subject: RFR: 8289231: Move java_lang_VirtualThread to
 continuationJavaClasses.hpp
In-Reply-To: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
References: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
Message-ID: <7FUAo_tQq1vIbp7nou_ELVzrYwGNiZcdr3JczUB70y8=.3acd2702-2744-49d5-aafc-4a493447e474@github.com>

On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a follow up to [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623). `java_lang_VirtualThread` is part of loom and should be move to continuationJavaClasses.hpp, which contains the accessors for the other java classes used by loom.

continuationJavaClasses.* is for the continuation support, I don't think it make sense to separate java_lang_VirtualThread from java_lang_Thread and other classes that support the Thread implementations and move it there.

-------------

PR: https://git.openjdk.org/jdk/pull/9298

From dlong at openjdk.org  Mon Jun 27 20:47:59 2022
From: dlong at openjdk.org (Dean Long)
Date: Mon, 27 Jun 2022 20:47:59 GMT
Subject: [jdk19] RFR: 8288949:
 serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java
 failing [v2]
In-Reply-To: <xg0f-ywbZNX8N8b5kKIiMdTL-cu7_CElflEuEhiswrw=.986a3c9a-5c31-4a4f-8f50-bea344358577@github.com>
References: <u0v1nyW8pNyYqz8tiSokhLxEcoD7LZhKCEweB7VD8gs=.a6a7a60b-a18e-400e-8c39-a35f0f0782a4@github.com>
 <xg0f-ywbZNX8N8b5kKIiMdTL-cu7_CElflEuEhiswrw=.986a3c9a-5c31-4a4f-8f50-bea344358577@github.com>
Message-ID: <jPc1g8xenecr5uaMuNpRwQBUo5qxnYKp6D2mA9i0YmY=.bb36d799-c43c-41eb-b6b0-957f03a59457@github.com>

On Sat, 25 Jun 2022 01:23:47 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Please review the following bug fix:
>> 
>> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`.
>> 
>> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode.
>> 
>> This change does three things:
>> 
>> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter.
>> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`.
>> 3. In interp_only_mode, the c2i stub will not patch the callsite.
>> 
>> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128
>> 
>> 
>> Passes tiers 1-4 and Loom tiers 1-5.
>
> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Remove outdated comment"
>   
>   This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe.

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/66

From ayang at openjdk.org  Mon Jun 27 22:19:35 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jun 2022 22:19:35 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>

> Simple rename and some comments update.
> 
> Test: build

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8332/files
  - new: https://git.openjdk.org/jdk/pull/8332/files/b1c0369a..f7a5f1e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8332&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8332&range=07-08

  Stats: 83 lines in 6 files changed: 29 ins; 44 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/8332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8332/head:pull/8332

PR: https://git.openjdk.org/jdk/pull/8332

From ayang at openjdk.org  Mon Jun 27 22:19:37 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Jun 2022 22:19:37 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v4]
In-Reply-To: <p8demOQ6ceLAYT5LkVHyhuGkC-PHEOdmjopk_5KaGcg=.384f6b9a-3d3c-45c5-b885-0aafef3ce7e4@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <fhxL1VQphAya_pTHlUwQFjJvnFOBqi3yFl_mdPXHRRg=.9a7a9c43-0d21-42a1-9fef-49f2cda8e9fc@github.com>
 <mQQfJ5VE0sRuuD1vF3WuheItcIT6q9E3o11e_XMwqaE=.8bf8c992-a92e-4e77-8f5b-3699354da233@github.com>
 <X_yKACFG-77rTfSDLsO4HVp_8pVoUYE35x-LjpD4Uqg=.bae211c2-8454-4659-8724-19d0cd8bb393@github.com>
 <S_xUtV-sDyAsxqzQMqej7iFxZWZCPsUdNxznfJFiZ0w=.d2c3b9af-6bcf-4c76-bfff-42a19549bc66@github.com>
 <rXuJHIXH8JkmrcO5uB2vrI5Uwl8-wiW24NB7JBl6oGI=.a0d17213-d669-4487-9bcb-c82697664052@github.com>
 <63A3vwzgxkFAtr--cfRniuGur2yTip7iPfX_y3Z4tsU=.15537746-5e1b-4a70-8dd8-aa128dbf7d50@github.com>
 <fzJRB4-F4rnRS4HKvBT_lCcohb4FTJ0R1rTyqhe4NeA=.a291dce1-1a0f-4f54-a3ee-7f7a3b04f062@github.com>
 <p8demOQ6ceLAYT5LkVHyhuGkC-PHEOdmjopk_5KaGcg=.384f6b9a-3d3c-45c5-b885-0aafef3ce7e4@github.com>
Message-ID: <oMMwzw6Hca_5xuGhNtjUQVc2i9PltM4sMSVpwcOrYc4=.10fef8fc-df34-4c86-b057-df25f515e4c9@github.com>

On Mon, 27 Jun 2022 14:27:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> The _reference_type used to be initialized correctly in most cases, but
>> needed fixing up for a few cases during bootstrapping. With this change it is
>> never initialized correctly for Reference subtypes and always needs an
>> initialization kludge for them. That's not an improvement.
>> 
>> I don't agree that this is a kludge. This is quite common in HotSpot, and the code is quite understandable. It's far better than the initialization kludge the code had before this patch.
>> 
>> I'd like to suggest that we go with the proposed patch, and consider the Kim's latest proposal as a follow-up RFE. That way we can make progress on this RFE, and then weigh the pros and cons of this suggestion separately.
>
> Talked to Albert. He's already created a patch for this, so I retract my objection to this blocking of the PR.

Revised as Kim suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From dholmes at openjdk.org  Mon Jun 27 22:58:41 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 27 Jun 2022 22:58:41 GMT
Subject: RFR: 8289231: Move java_lang_VirtualThread to
 continuationJavaClasses.hpp
In-Reply-To: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
References: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
Message-ID: <DvltfV4v66kQZeej2auSNkpyxeErH0Z9gOgjVCnFAU8=.66838b21-672e-40cf-ad6d-544734daa79c@github.com>

On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a follow up to [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623). `java_lang_VirtualThread` is part of loom and should be move to continuationJavaClasses.hpp, which contains the accessors for the other java classes used by loom.

@iklam I tend to agree with @AlanBateman . The file is not loomJavaClasses but continuationJavaClasses.

-------------

PR: https://git.openjdk.org/jdk/pull/9298

From kbarrett at openjdk.org  Tue Jun 28 00:54:06 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 28 Jun 2022 00:54:06 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]
In-Reply-To: <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
Message-ID: <0Nl0skMW_HdDnDZobqRndUm7gptDuAmWyMenFZE2iIA=.b860cc2e-0e0b-4a30-a36f-06602d279bae@github.com>

On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

Just a couple of minor "naming" comments, that you can address or not.

src/hotspot/share/classfile/classFileParser.cpp line 6115:

> 6113:   // j.l.r.Reference cannot be instantiated so doesn't partake in
> 6114:   // ref-processing.
> 6115:   return is_java_lang_ref_Reference_subclass();

This seems to be the only call to this function, so the definition could just be inlined here and drop the separate function.

src/hotspot/share/classfile/classFileParser.hpp line 566:

> 564: 
> 565:   bool is_instance_ref_klass() const;
> 566:   ReferenceType determine_reference_type() const;

I'd prefer this was just called `reference_type`.  Like much of the API here, this is about a property of the designated klass.  That it's no longer just a data member accessor is of no particular importance.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8332

From jbhateja at openjdk.org  Tue Jun 28 06:11:49 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 28 Jun 2022 06:11:49 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

src/hotspot/cpu/x86/x86_64.ad line 13027:

> 13025: // Manifest a CmpU result in an integer register.  Very painful.
> 13026: // This is the test to avoid.
> 13027: instruct cmpU3_reg_reg(rRegI dst, rRegI src1, rRegI src2, rFlagsReg flags)

Do you plan to add 32 bit support?
Integer pattern can be moved to common file x86.ad and 64 pattern can handled in 32/64 bit AD files.

src/hotspot/cpu/x86/x86_64.ad line 13043:

> 13041:     __ cmpl($src1$$Register, $src2$$Register);
> 13042:     __ movl($dst$$Register, -1);
> 13043:     __ jccb(Assembler::below, done);

By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
Kindly refer section 3.4.2.2 of Intel's optimization manual.

src/hotspot/cpu/x86/x86_64.ad line 13095:

> 13093:     __ cmpq($src1$$Register, $src2$$Register);
> 13094:     __ movl($dst$$Register, -1);
> 13095:     __ jccb(Assembler::below, done);

Same as above.

src/hotspot/share/opto/subnode.hpp line 185:

> 183:   }
> 184:   virtual int Opcode() const;
> 185:   virtual uint ideal_reg() const { return Op_RegI; }

Value routine to handle constant folding.

src/hotspot/share/opto/subnode.hpp line 247:

> 245:     init_class_id(Class_Sub);
> 246:   }
> 247:   virtual int Opcode() const;

In-lining may connect the inputs to constant, hence a Value routine may be useful here.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From iklam at openjdk.org  Tue Jun 28 06:28:35 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 06:28:35 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of os_xxx.hpp
Message-ID: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>

There are only two implementations of these classes (one for windows, and one for posix):

- PlatformEvent
- PlatformParker
- PlatformMutex
- PlatformMonitor
- ThreadCrashProtection

Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp

This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.

Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

-------------

Commit messages:
 - fixed windows
 - Moved PlatformMutex/PlatformMonitor
 - move-PlatformParker-out-of-os-xxx-hpp
 - Moved ThreadCrashProtection

Changes: https://git.openjdk.org/jdk/pull/9303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289230
  Stats: 1168 lines in 35 files changed: 705 ins; 386 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

PR: https://git.openjdk.org/jdk/pull/9303

From duke at openjdk.org  Tue Jun 28 06:32:43 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 06:32:43 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
Message-ID: <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>

On Tue, 28 Jun 2022 05:51:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comparison for direct value of compare
>
> src/hotspot/cpu/x86/x86_64.ad line 13027:
> 
>> 13025: // Manifest a CmpU result in an integer register.  Very painful.
>> 13026: // This is the test to avoid.
>> 13027: instruct cmpU3_reg_reg(rRegI dst, rRegI src1, rRegI src2, rFlagsReg flags)
> 
> Do you plan to add 32 bit support?
> Integer pattern can be moved to common file x86.ad and 64 pattern can handled in 32/64 bit AD files.

Yes I will add support for 32-bit after this patch, basic rules are often put in the bit-specific ad file so I think it would be more preferable to follow that convention here.

> src/hotspot/share/opto/subnode.hpp line 247:
> 
>> 245:     init_class_id(Class_Sub);
>> 246:   }
>> 247:   virtual int Opcode() const;
> 
> In-lining may connect the inputs to constant, hence a Value routine may be useful here.

`CmpU3` inherits the `Value` method from its superclass `CmpU`

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From dholmes at openjdk.org  Tue Jun 28 07:24:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Jun 2022 07:24:52 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>

On Tue, 28 Jun 2022 06:16:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

Just took a quick skim through to get the general sense of things. Header file split is okay. Pity about the .cpp situation though - maybe move to platform_posix.cpp and platform_windows.cpp to at least get them out of the os_xxx.cpp file?

src/hotspot/os/posix/mutex_posix.hpp line 141:

> 139: };
> 140: 
> 141: #endif // OS_POSIX_PARK_POSIX_HPP

Wrong comment.

src/hotspot/os/posix/threadCrashProtection_posix.cpp line 38:

> 36: 
> 37: /*
> 38:  * See the caveats for this class in os_posix.hpp

Comment needs updating

src/hotspot/os/windows/mutex_windows.hpp line 64:

> 62: };
> 63: 
> 64: #endif // OS_WINDOWS_PARK_WINDOWS_HPP

Wrong comment

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From ehelin at openjdk.org  Tue Jun 28 07:38:40 2022
From: ehelin at openjdk.org (Erik Helin)
Date: Tue, 28 Jun 2022 07:38:40 GMT
Subject: RFR: 8289138: G1: Remove redundant is-marking-active checks in C1
 barrier
In-Reply-To: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
References: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
Message-ID: <9jXanuOA8E3sh4gbLeJ5r8f3SimqsOxnJvr-FYjjgZE=.9c792722-3ff6-4faf-b5a0-a1541e7706de@github.com>

On Fri, 24 Jun 2022 12:00:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant check in C1 barrier code.
> 
> Test: tier1-3

Looks good, thanks for fixing!

-------------

Marked as reviewed by ehelin (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9274

From jbhateja at openjdk.org  Tue Jun 28 07:39:41 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 28 Jun 2022 07:39:41 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <XHxgsemfZU45zxBXyKgkdOXyF5AgZc3tFrc224_eRR4=.13a1cccd-cccc-42e5-bcb9-9a0b389ee75e@github.com>
Message-ID: <QLnfxHEgKbiD8k7sbZoxrCkZwMScDrABCKql0k7UjbQ=.edb5c5db-7735-49ff-b844-610343fc58e3@github.com>

On Tue, 28 Jun 2022 06:29:03 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> src/hotspot/share/opto/subnode.hpp line 247:
>> 
>>> 245:     init_class_id(Class_Sub);
>>> 246:   }
>>> 247:   virtual int Opcode() const;
>> 
>> In-lining may connect the inputs to constant, hence a Value routine may be useful here.
>
> `CmpU3` inherits the `Value` method from its superclass `CmpU`

Its fine then.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From stefank at openjdk.org  Tue Jun 28 11:06:49 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 28 Jun 2022 11:06:49 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]
In-Reply-To: <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
Message-ID: <grysiC3K5_YLD6nAFsj3aQruq0aMKyHO17_TEZXuH3A=.7c1137d0-9221-440e-a4ad-79b9441cc796@github.com>

On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good. +1 on Kim's latest comments.

-------------

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8332

From stefank at openjdk.org  Tue Jun 28 11:21:43 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 28 Jun 2022 11:21:43 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v9]
In-Reply-To: <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <c7Qc6jDaq_4C0WEtI3709XXMGVnRXQyojJdpWB8CwYI=.751c7d68-5de9-47ca-ab69-7267d368c37b@github.com>
Message-ID: <dF-DyLKxPTXMJ4oBrN7x7bM3MKD5ZB2JvGbloM8DMdQ=.ab49cf7e-2e9d-4205-a7ee-77d6dc2875b0@github.com>

On Mon, 27 Jun 2022 22:19:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Scratch my last comment. This crashes in GHA, because determine_reference_type() now gets called from non-InstanceRefKlass InstanceKlasses, which is wasn't written to support.

-------------

Changes requested by stefank (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8332

From ayang at openjdk.org  Tue Jun 28 11:59:09 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Jun 2022 11:59:09 GMT
Subject: RFR: 8289138: G1: Remove redundant is-marking-active checks in C1
 barrier
In-Reply-To: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
References: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
Message-ID: <QuR0YAsJNmvNlRNVos3TfQJHgK8TROk4pfd5uHJXdjg=.0870f2ed-8595-4ca6-a215-2ddc7eb5a37a@github.com>

On Fri, 24 Jun 2022 12:00:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant check in C1 barrier code.
> 
> Test: tier1-3

Thanks for the review.

-------------

PR: https://git.openjdk.org/jdk/pull/9274

From ayang at openjdk.org  Tue Jun 28 11:59:09 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Jun 2022 11:59:09 GMT
Subject: Integrated: 8289138: G1: Remove redundant is-marking-active checks in
 C1 barrier
In-Reply-To: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
References: <3Df_hQbe2GdBLeHTcs8u_5LMVE7tY5i2iKGHifPf0vM=.b60bead5-60a2-42da-ac65-14bd02a5f8b0@github.com>
Message-ID: <Qo3sLD5iISHApQqluvP6IrTFGRqpN4kIqDxHN5FTRAE=.46f6020f-158f-485b-a4fc-c04bdb930fe0@github.com>

On Fri, 24 Jun 2022 12:00:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant check in C1 barrier code.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: aa438242
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa438242493f2dcc2e372b971abf384fd482e763
Stats:     51 lines in 6 files changed: 0 ins; 51 del; 0 mod

8289138: G1: Remove redundant is-marking-active checks in C1 barrier

Reviewed-by: tschatzl, ehelin

-------------

PR: https://git.openjdk.org/jdk/pull/9274

From duke at openjdk.org  Tue Jun 28 12:06:45 2022
From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=)
Date: Tue, 28 Jun 2022 12:06:45 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
 <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
Message-ID: <Bqtu6GeMH21JQbP7YBR2xTlhMZFwQ8o0KN_wuXsPqCM=.e23843f8-f031-4084-be9d-0cbbdeaaca0c@github.com>

On Thu, 23 Jun 2022 09:42:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> The current implementation do not count all monitor enter, counts high up in abstraction and causes a performance regression on aarch64 with some benchmarks due to C2 changes.
>> 
>> This change makes the counting exact by pushing the counting down in the abstraction.
>> The additional JNI counter is strictly not needed, but enables us to figure out if we have monitors "on stack".
>> 
>> An uncontended lock plus unlock is 1 ns (21.5 -> 22.5) slower in C2 compiled code on x64 with the additional increment and decrement.
>> 
>> Fixed aarch64, x64, x86 and zero.
>> 
>> Passes t1-8
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into held-mon-count
>  - 8286957 - PR Baseline

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 629:

> 627:         mon->lock()->set_displaced_header(displaced);
> 628:         bool call_vm = UseHeavyMonitors;
> 629:         bool inc_mon_count = true;

Should be inc_mon**t**_count? We're consistent with `dec_mont_count`.

-------------

PR: https://git.openjdk.org/jdk/pull/8945

From rpressler at openjdk.org  Tue Jun 28 12:33:00 2022
From: rpressler at openjdk.org (Ron Pressler)
Date: Tue, 28 Jun 2022 12:33:00 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
 <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
Message-ID: <qY-856kl2tBCY4AThIkzZUxBYC6xQX0ahlpw4qeIqjA=.e40ccdd7-18d0-41cf-8f9c-54ce7eeb21a6@github.com>

On Thu, 23 Jun 2022 09:42:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> The current implementation do not count all monitor enter, counts high up in abstraction and causes a performance regression on aarch64 with some benchmarks due to C2 changes.
>> 
>> This change makes the counting exact by pushing the counting down in the abstraction.
>> The additional JNI counter is strictly not needed, but enables us to figure out if we have monitors "on stack".
>> 
>> An uncontended lock plus unlock is 1 ns (21.5 -> 22.5) slower in C2 compiled code on x64 with the additional increment and decrement.
>> 
>> Fixed aarch64, x64, x86 and zero.
>> 
>> Passes t1-8
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into held-mon-count
>  - 8286957 - PR Baseline

Marked as reviewed by rpressler (Author).

-------------

PR: https://git.openjdk.org/jdk/pull/8945

From dholmes at openjdk.org  Tue Jun 28 12:43:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Jun 2022 12:43:47 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <Bqtu6GeMH21JQbP7YBR2xTlhMZFwQ8o0KN_wuXsPqCM=.e23843f8-f031-4084-be9d-0cbbdeaaca0c@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
 <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
 <Bqtu6GeMH21JQbP7YBR2xTlhMZFwQ8o0KN_wuXsPqCM=.e23843f8-f031-4084-be9d-0cbbdeaaca0c@github.com>
Message-ID: <6L_IXz43fwMvolqBrhM40MANMz-CGrzh472MKEsHpuE=.0ac4e22d-c885-46b4-b78c-90441070473e@github.com>

On Tue, 28 Jun 2022 09:08:04 GMT, Johan Sj?l?n <duke at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into held-mon-count
>>  - 8286957 - PR Baseline
>
> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 629:
> 
>> 627:         mon->lock()->set_displaced_header(displaced);
>> 628:         bool call_vm = UseHeavyMonitors;
>> 629:         bool inc_mon_count = true;
> 
> Should be inc_mon**t**_count? We're consistent with `dec_mont_count`.

Please do not use `mont` as an abbreviation for monitor - use `mon` or `monitor`. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/8945

From duke at openjdk.org  Tue Jun 28 12:46:43 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 12:46:43 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <J43htIhhRp0LuUsSDOaRuouD4zyPbR43L2SQWBUqgBU=.ac9a8c98-a052-4604-a3c3-1a8afca95ac6@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

@jatin-bhateja Thanks a lot for your reviews and suggestions, I have answered your comments.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Tue Jun 28 12:46:45 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Tue, 28 Jun 2022 12:46:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
Message-ID: <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>

On Tue, 28 Jun 2022 05:20:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comparison for direct value of compare
>
> src/hotspot/cpu/x86/x86_64.ad line 13043:
> 
>> 13041:     __ cmpl($src1$$Register, $src2$$Register);
>> 13042:     __ movl($dst$$Register, -1);
>> 13043:     __ jccb(Assembler::below, done);
> 
> By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
> Kindly refer section 3.4.2.2 of Intel's optimization manual.

I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From coleen.phillimore at oracle.com  Tue Jun 28 12:59:31 2022
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 28 Jun 2022 08:59:31 -0400
Subject: Obsoleting JavaCritical
In-Reply-To: <20220607103108.900830823@eggemoggin.niobe.net>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
 <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
 <20220607103108.900830823@eggemoggin.niobe.net>
Message-ID: <cb7f4e85-6934-629a-d3d1-892dd3dc9b42@oracle.com>


Hi,

I've filed https://bugs.openjdk.org/browse/JDK-8289302 to restore 
CriticalJNINatives until replacement intrinsics are found.

Thanks,
Coleen

On 6/7/22 1:31 PM, mark.reinhold at oracle.com wrote:
> 2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>>> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>>> CLOCK_REALTIME.
>> Unfortunately System.currentTimeMillis() offers only millisecond
>> granularity which is the reason why our industry has to resort to
>> clock_gettime.
> If the platform included, say, an intrinsified System.nanoRealTime()
> method that returned clock_gettime(CLOCK_REALTIME), how much would
> that help developers in your unnamed industry?
>
> In a similar vein, if people are finding it necessary to ?replace parts
> of NIO with hand-crafted native code? then it would be interesting to
> understand what their requirements are.  Some simple enhancements to
> the NIO API would be much less costly to design and implement than a
> generalized user-level native-call intrinsification mechanism.
>
> - Mark


From dnsimon at openjdk.org  Tue Jun 28 13:27:09 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 28 Jun 2022 13:27:09 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds trips in
 JVMCI
Message-ID: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>

The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
2. SVM: Native to VM (enter SVM)
3. SVM: VM to native (exit SVM)
4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)

When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.

There are other smaller changes to reduce JNI overhead included in this PR:
* Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
* Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
* Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
* Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.

This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

-------------

Commit messages:
 - reduce JNI overhead and other VM rounds trips in JVMCI

Changes: https://git.openjdk.org/jdk/pull/9305/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9305&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289094
  Stats: 4488 lines in 53 files changed: 2492 ins; 992 del; 1004 mod
  Patch: https://git.openjdk.org/jdk/pull/9305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9305/head:pull/9305

PR: https://git.openjdk.org/jdk/pull/9305

From dnsimon at openjdk.org  Tue Jun 28 13:27:11 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 28 Jun 2022 13:27:11 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
Message-ID: <EANOeVxhl-I6x80WyqtbvO2KAJ5lRBQSUS5hb6E1QP4=.77e1401f-affa-4607-81b5-4c4eea25ce4a@github.com>

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

src/hotspot/share/runtime/timer.hpp line 41:

> 39:   elapsedTimer()             { _active = false; reset(); }
> 40:   void add(elapsedTimer t);
> 41:   void add_nanoseconds(jlong ns);

This is required so that code installation work done in libjvmci can be properly [attributed to a VM based timer](https://github.com/openjdk/jdk/pull/9305/files#diff-c8d24aa5ec59cf15ded545e3a34a1546758691a96bfe1342fdcb2aaf9cf9a696R936).

src/hotspot/share/utilities/ostream.hpp line 103:

> 101:    void print_raw_cr(const char* str)         { write(str, strlen(str)); cr(); }
> 102:    void print_raw_cr(const char* str, size_t len){ write(str,         len); cr(); }
> 103:    void print_data(void* data, size_t len, bool with_ascii, bool rel_addr=true);

This allows for hex dumps to show absolute addresses which is important for comparing a buffer [written in Java](https://github.com/openjdk/jdk/pull/9305/files#diff-d290f5a7a572ba7d4f0c7d234eb73de6537a2aa1d02726527d8db0df23c874b7R118-R134) and [read in C++](https://github.com/openjdk/jdk/pull/9305/files#diff-5e4a9ef468fc0f1564d6cfbe98f44b1099842098366cbec4103710137b2022edR34-R36).

-------------

PR: https://git.openjdk.org/jdk/pull/9305

From erik.osterlund at oracle.com  Tue Jun 28 16:04:25 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Tue, 28 Jun 2022 16:04:25 +0000
Subject: Obsoleting JavaCritical
In-Reply-To: <cb7f4e85-6934-629a-d3d1-892dd3dc9b42@oracle.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
 <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
 <20220607103108.900830823@eggemoggin.niobe.net>
 <cb7f4e85-6934-629a-d3d1-892dd3dc9b42@oracle.com>
Message-ID: <0FDB5508-907A-466C-96D1-CD7AE5274DE8@oracle.com>

Hi,

Generational ZGC currently depends on CriticalJNINatives not existing, which was a valid move when it was removed. We didn?t anticipate it would suddenly come back from the dead. Ouch.

/Erik

> On 28 Jun 2022, at 15:46, coleen.phillimore at oracle.com wrote:
> 
> ?
> Hi,
> 
> I've filed https://bugs.openjdk.org/browse/JDK-8289302 to restore CriticalJNINatives until replacement intrinsics are found.
> 
> Thanks,
> Coleen
> 
>> On 6/7/22 1:31 PM, mark.reinhold at oracle.com wrote:
>> 2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>>>> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>>>> CLOCK_REALTIME.
>>> Unfortunately System.currentTimeMillis() offers only millisecond
>>> granularity which is the reason why our industry has to resort to
>>> clock_gettime.
>> If the platform included, say, an intrinsified System.nanoRealTime()
>> method that returned clock_gettime(CLOCK_REALTIME), how much would
>> that help developers in your unnamed industry?
>> 
>> In a similar vein, if people are finding it necessary to ?replace parts
>> of NIO with hand-crafted native code? then it would be interesting to
>> understand what their requirements are.  Some simple enhancements to
>> the NIO API would be much less costly to design and implement than a
>> generalized user-level native-call intrinsification mechanism.
>> 
>> - Mark
> 

From kvn at openjdk.org  Tue Jun 28 16:20:47 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 28 Jun 2022 16:20:47 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
Message-ID: <adK9ZFKn9OnNuKQXM7mNJ06M7jAv0k-1VLLP77R5nNQ=.4c230cc7-c062-4db6-9b90-2ca616d120cf@github.com>

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

Seems fine.  Please add link to mach5 testing results to RFE.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9305

From duke at openjdk.org  Tue Jun 28 16:41:36 2022
From: duke at openjdk.org (Yi-Fan Tsai)
Date: Tue, 28 Jun 2022 16:41:36 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v3]
In-Reply-To: <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
Message-ID: <z4wpF0PBHdT1DemRFHDxD2xPyOKNk89Y6KjZIOYSCH8=.56d5927f-40e3-441d-9e40-63be3a63f4a2@github.com>

On Fri, 3 Jun 2022 18:06:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Post dynamic_code_generate event when MH intrinsic generated
>
> src/hotspot/share/code/codeBlob.cpp line 347:
> 
>> 345:   {
>> 346:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>> 347:     int mhi_size = CodeBlob::allocation_size(code_buffer, sizeof(MethodHandleIntrinsicBlob));
> 
> The allocation size could also be computed before taking the code cache lock. BufferBlob also does this for example, but others don't. I think it makes sense to have it outside of the mutex block though, to minimize the time we need to hold the lock. I don't see anything in there that seems to require the lock. (Maybe we should clean up other cases in a followup as well).

The issue was [filed](https://bugs.openjdk.org/browse/JDK-8289071) and [fixed](https://github.com/openjdk/jdk/pull/9266).

-------------

PR: https://git.openjdk.org/jdk/pull/8760

From iklam at openjdk.org  Tue Jun 28 18:38:10 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:38:10 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9303/files
  - new: https://git.openjdk.org/jdk/pull/9303/files/27ddeb07..8ceda0f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

PR: https://git.openjdk.org/jdk/pull/9303

From iklam at openjdk.org  Tue Jun 28 18:38:11 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:38:11 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
Message-ID: <eDfvGWE0Ud3oL8xoERK7F9o64cRKUpAWa8mgaY4iFQE=.f5fc18f7-fbbf-4c80-844c-8138e89f0d3e@github.com>

On Tue, 28 Jun 2022 07:15:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> src/hotspot/os/posix/mutex_posix.hpp line 141:
> 
>> 139: };
>> 140: 
>> 141: #endif // OS_POSIX_PARK_POSIX_HPP
> 
> Wrong comment.

Fixed.

> src/hotspot/os/posix/threadCrashProtection_posix.cpp line 38:
> 
>> 36: 
>> 37: /*
>> 38:  * See the caveats for this class in os_posix.hpp
> 
> Comment needs updating

Fixed.

> src/hotspot/os/windows/mutex_windows.hpp line 64:
> 
>> 62: };
>> 63: 
>> 64: #endif // OS_WINDOWS_PARK_WINDOWS_HPP
> 
> Wrong comment

Fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From iklam at openjdk.org  Tue Jun 28 18:41:50 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:41:50 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
Message-ID: <43iMsTyIQcqIf0SEztkB3zFld8tC6HERJyzeocytq4c=.8cbcd72f-642b-4af2-90fa-3f2c3f98e400@github.com>

On Tue, 28 Jun 2022 07:20:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just took a quick skim through to get the general sense of things. Header file split is okay. Pity about the .cpp situation though - maybe move to platform_posix.cpp and platform_windows.cpp to at least get them out of the os_xxx.cpp file?

Unfortunately it's worse than I thought. There's a static function, `to_abstime()` that shared between `os::Posix::to_RTC_abstime()` and the `PlatformEvent::park()`.

To clean things up, I would need to move some static fields/functions into the `os::Posix` class. Maybe I should do the refactoring in a separate PR, to keep this PR simple?

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From coleenp at openjdk.org  Tue Jun 28 19:42:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 28 Jun 2022 19:42:44 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
Message-ID: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>

On Tue, 28 Jun 2022 18:38:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comments

I very much like this incremental approach to reducing our over-inclusion.

src/hotspot/share/runtime/mutex.hpp line 203:

> 201:   #ifndef PRODUCT
> 202:     void print_on(outputStream* st) const;
> 203:     void print() const                      { /*print_on(::tty); */ } // FIXME

Can you move this print implementation into the .cpp file?

src/hotspot/share/runtime/threadCrashProtection.hpp line 42:

> 40: #else
> 41: # error "No ThreadCrashProtection implementation provided for this OS"
> 42: #endif

Shouldn't you use this?
#define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9303

From ayang at openjdk.org  Tue Jun 28 19:43:33 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Jun 2022 19:43:33 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v10]
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>

> Simple rename and some comments update.
> 
> Test: build

Albert Mingkun Yang has updated the pull request incrementally with four additional commits since the last revision:

 - arg rename
 - default arg
 - revert
 - fix-build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8332/files
  - new: https://git.openjdk.org/jdk/pull/8332/files/f7a5f1e6..1e4c71ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8332&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8332&range=08-09

  Stats: 74 lines in 6 files changed: 33 ins; 29 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/8332.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8332/head:pull/8332

PR: https://git.openjdk.org/jdk/pull/8332

From jvernee at openjdk.org  Tue Jun 28 19:44:28 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 28 Jun 2022 19:44:28 GMT
Subject: RFR: 8263377: Store method handle linkers in the 'non-nmethods'
 heap [v3]
In-Reply-To: <z4wpF0PBHdT1DemRFHDxD2xPyOKNk89Y6KjZIOYSCH8=.56d5927f-40e3-441d-9e40-63be3a63f4a2@github.com>
References: <GCg9SEA8g9CdfCYM3gfEhigEFCqDqOFuE6VIZCfBUM8=.3a31e490-4f37-49a4-a3c6-da91dcf1e39b@github.com>
 <Ys99HGzOAiWf9Je5hgmmNoXq22t_15n9factK1HweCM=.6263da56-f447-4f77-8dcb-051979d9b637@github.com>
 <z4wpF0PBHdT1DemRFHDxD2xPyOKNk89Y6KjZIOYSCH8=.56d5927f-40e3-441d-9e40-63be3a63f4a2@github.com>
Message-ID: <9w1jl4SXtQ_STu3LFt1yv2YqcfMZHvlPRYLUGg4UN3k=.eb2e7a84-d6ce-4577-9488-5efe7e3a242b@github.com>

On Tue, 28 Jun 2022 16:38:20 GMT, Yi-Fan Tsai <duke at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.cpp line 347:
>> 
>>> 345:   {
>>> 346:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>>> 347:     int mhi_size = CodeBlob::allocation_size(code_buffer, sizeof(MethodHandleIntrinsicBlob));
>> 
>> The allocation size could also be computed before taking the code cache lock. BufferBlob also does this for example, but others don't. I think it makes sense to have it outside of the mutex block though, to minimize the time we need to hold the lock. I don't see anything in there that seems to require the lock. (Maybe we should clean up other cases in a followup as well).
>
> The issue was [filed](https://bugs.openjdk.org/browse/JDK-8289071) and [fixed](https://github.com/openjdk/jdk/pull/9266).

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/8760

From kbarrett at openjdk.org  Tue Jun 28 19:48:41 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 28 Jun 2022 19:48:41 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v10]
In-Reply-To: <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
Message-ID: <axn0pXMNbpo46wgh90pZRkeOtRzGS6JdXT5C2FOtCwM=.9ad3199b-b50d-4dd2-a07e-4a830bee6b53@github.com>

On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - arg rename
>  - default arg
>  - revert
>  - fix-build

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8332

From iklam at openjdk.org  Tue Jun 28 20:13:01 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 20:13:01 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v3]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @coleenp comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9303/files
  - new: https://git.openjdk.org/jdk/pull/9303/files/8ceda0f5..9d502ffb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=01-02

  Stats: 21 lines in 5 files changed: 4 ins; 11 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

PR: https://git.openjdk.org/jdk/pull/9303

From iklam at openjdk.org  Tue Jun 28 20:13:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 20:13:04 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
Message-ID: <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>

On Tue, 28 Jun 2022 19:37:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> src/hotspot/share/runtime/mutex.hpp line 203:
> 
>> 201:   #ifndef PRODUCT
>> 202:     void print_on(outputStream* st) const;
>> 203:     void print() const                      { /*print_on(::tty); */ } // FIXME
> 
> Can you move this print implementation into the .cpp file?

Fixed.

> src/hotspot/share/runtime/threadCrashProtection.hpp line 42:
> 
>> 40: #else
>> 41: # error "No ThreadCrashProtection implementation provided for this OS"
>> 42: #endif
> 
> Shouldn't you use this?
> #define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)

I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From coleenp at openjdk.org  Tue Jun 28 21:10:43 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 28 Jun 2022 21:10:43 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
Message-ID: <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>

On Tue, 28 Jun 2022 20:08:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadCrashProtection.hpp line 42:
>> 
>>> 40: #else
>>> 41: # error "No ThreadCrashProtection implementation provided for this OS"
>>> 42: #endif
>> 
>> Shouldn't you use this?
>> #define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)
>
> I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.

Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From jwilhelm at openjdk.org  Tue Jun 28 21:21:12 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 21:21:12 GMT
Subject: RFR: Merge jdk19
Message-ID: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again
 - 8289069: Very slow C1 arraycopy jcstress tests after JDK-8279886
 - 8288058: Broken links on constant-values page
 - 8275784: Bogus warning generated for record with compact constructor
 - 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory
 - 8289228: SegmentAllocator::allocateArray null handling is too lax
 - 8288445: AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
 - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java
 - ... and 7 more: https://git.openjdk.org/jdk/compare/af008807...d57b485f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9315/files
  Stats: 821 lines in 29 files changed: 612 ins; 71 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

PR: https://git.openjdk.org/jdk/pull/9315

From dlong at openjdk.org  Tue Jun 28 21:56:39 2022
From: dlong at openjdk.org (Dean Long)
Date: Tue, 28 Jun 2022 21:56:39 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
Message-ID: <oEE-vnlfSdp2jSdWTErwYQb_M0x6n0ACfS6ycZJTLiE=.9a301559-0bf2-4e1d-96cc-f8cccd222852@github.com>

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

I took a quick look and didn't find any problems.  It's clever how the tag values are synchronized.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9305

From jwilhelm at openjdk.org  Tue Jun 28 22:17:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:09 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <gtYlusBVnnkYR36SyDWKK3AhTK2FpOpGi5Wx7ZqufwI=.dcb880bf-bbbe-48c1-9985-75d302d4cf45@github.com>

On Tue, 28 Jun 2022 21:13:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 86dc760f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86dc760f9ec0f403109bef7b06db82b9ed0739dd
Stats:     821 lines in 29 files changed: 612 ins; 71 del; 138 mod

Merge

-------------

PR: https://git.openjdk.org/jdk/pull/9315

From jwilhelm at openjdk.org  Tue Jun 28 22:17:08 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:08 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <cubHA4OFa8jwOIA-LZWGABo7MOx2vWK4HxANnyER4kM=.ebc33bd9-ee29-4dc6-8d77-98203c0ffcc4@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 166 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8284640: CollectorImpl class could be a record class
   
   Reviewed-by: phh, rriggs
 - 8288961: jpackage: test MSI installation fix
   
   Reviewed-by: asemenyuk, almatvee
 - 8288013: jpackage: test utility Windows registry enhancement
   
   Reviewed-by: asemenyuk, almatvee
 - 8289071: Compute allocation sizes of stubs and nmethods outside of lock protection
   
   Reviewed-by: thartmann, phh
 - 8271252: os::reserve_memory should not use mtOther as default NMT flag
   
   Reviewed-by: zgu
 - 8287818: Shenandoah: adapt nmethod arming from Loom
   
   Reviewed-by: shade
 - 8289138: G1: Remove redundant is-marking-active checks in C1 barrier
   
   Reviewed-by: tschatzl, ehelin
 - 8288396: Always create reproducible builds
   
   Reviewed-by: amenkov, ehelin
 - 8289258: ProblemList some failing custom loader tests with ZGC
   
   Reviewed-by: dholmes
 - ... and 156 more: https://git.openjdk.org/jdk/compare/15048048...d57b485f

-------------

Changes: https://git.openjdk.org/jdk/pull/9315/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=01
  Stats: 68839 lines in 1210 files changed: 43242 ins; 13434 del; 12163 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

PR: https://git.openjdk.org/jdk/pull/9315

From iklam at openjdk.org  Tue Jun 28 22:47:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 22:47:42 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
 <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
Message-ID: <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>

On Tue, 28 Jun 2022 21:02:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.
>
> Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.

` OS_HEADER(threadCrashProtection)` will give threadCrashProtection_linux.hpp, etc. It won't give us threadCrashProtection_posix.hpp. I didn't want to write three threadCrashProtection_{aix,bsd,linux}.hpp files that each just has a single line that includes the _posix version.

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From kvn at openjdk.org  Tue Jun 28 23:40:38 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 28 Jun 2022 23:40:38 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
 <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
Message-ID: <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>

On Tue, 21 Jun 2022 18:35:33 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> > GHA testing is not clean.
> > I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.
> 
> Vladimir(@vnkozlov), Have you got testing results?

What I meant is that I will not submit my own testing until GitHub action testing is clean. Which is not which means something is wrong with changes:
https://github.com/openjdk/jdk/pull/8816/checks?check_run_id=6998367114

Please, fix issues and update to latest JDK sources.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From jbhateja at openjdk.org  Wed Jun 29 02:15:38 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 02:15:38 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
Message-ID: <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>

On Tue, 28 Jun 2022 12:42:57 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 13043:
>> 
>>> 13041:     __ cmpl($src1$$Register, $src2$$Register);
>>> 13042:     __ movl($dst$$Register, -1);
>>> 13043:     __ jccb(Assembler::below, done);
>> 
>> By placing compare adjacent to conditional jump in-order frontend can trigger macro-fusion. 
>> Kindly refer section 3.4.2.2 of Intel's optimization manual.
>
> I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.

I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Wed Jun 29 02:25:39 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 02:25:39 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
 <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
Message-ID: <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>

On Wed, 29 Jun 2022 02:12:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I realised that by swapping the `mov` and the `cmp` instruction, the rule needs to have `dst` different from `src1` and `src2`, which increases register pressure.
>
> I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.

Your suggestion requires us having additional `TEMP dst` for the match rule. Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From dholmes at openjdk.org  Wed Jun 29 03:05:39 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Jun 2022 03:05:39 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
Message-ID: <LH-SAw-WXB9WmL0cfQkKYTHCBnaSNbG0IFPp6Iyp4gw=.05594463-beaa-48c9-a9a4-2314564ea578@github.com>

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

Hi Doug,

I just looked at the general runtime changes and they seem okay.

Thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/9305

From jbhateja at openjdk.org  Wed Jun 29 04:23:45 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 04:23:45 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
 <Vi31UAB--pYgGvyJLq3-qNHA2IlS0Cu_WobfslcBxT4=.94b26ada-e700-4771-a990-2ae6a466d40d@github.com>
 <n00L6CJNiJKfEK6wcQMCZ1PJPXSK0Inj82YdfKJQ0VU=.81732c02-19be-442a-8b5d-09816e338856@github.com>
 <VFn3GC5zqMcQu3eqRRnl7rirlVQpk_PkPUvxoCvBJbA=.2618fc87-df2e-4ddf-aa28-15a416d4b2e8@github.com>
 <e4HvqQqaP7FqZQwJlCkPNpE3krYWOHs5iD8PhHl_9a0=.c0dd82fd-7a52-49a8-b83c-b02a8c83d464@github.com>
Message-ID: <t-GCTicCLWNtEIcxgHgK4DeINe2XJWdY87mXSpn6Fjo=.fa5ed48c-5d80-4a8d-b082-bb91e3731237@github.com>

On Wed, 29 Jun 2022 02:22:02 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> I do not follow your comment, allocation decisions purely based on LRGs interferences and data flow attributes attached to operands and is agnostic to encoding block contents.
>
> Your suggestion requires us having additional `TEMP dst` for the match rule. Thanks.

Yes, macro fusion is a fine microarchitectural optimization which can reduce load on entire execution pipeline and is **deterministic** for specific pair of cmp + jump instructions, you have aggregated destination's defs and its usages towards the tail which can save TEMP attribution on destination operand and may save a redundant spill only for high register pressure blocks. I am ok with existing handling.

Thanks for your explanations.

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From dholmes at openjdk.org  Wed Jun 29 04:49:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Jun 2022 04:49:23 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
 <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
 <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>
Message-ID: <CeKhX5WDi1VH-bgCcmhw3Ljd733P8y439ShT63599Ro=.d5e8e436-4e88-4568-b439-49f3b9a33678@github.com>

On Tue, 28 Jun 2022 22:44:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.
>
> ` OS_HEADER(threadCrashProtection)` will give threadCrashProtection_linux.hpp, etc. It won't give us threadCrashProtection_posix.hpp. I didn't want to write three threadCrashProtection_{aix,bsd,linux}.hpp files that each just has a single line that includes the _posix version.

Yeah no posix support with OS_HEADER.

-------------

PR: https://git.openjdk.org/jdk/pull/9303

From jbhateja at openjdk.org  Wed Jun 29 06:09:33 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 29 Jun 2022 06:09:33 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <452dySWhqSw4rDXLA1MQR3x3Nz3Xt4wYdJ0j7UYCVyA=.a3acfa1c-658b-4313-927a-0c47146a79e7@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

Marked as reviewed by jbhateja (Committer).

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From duke at openjdk.org  Wed Jun 29 07:20:42 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 07:20:42 GMT
Subject: RFR: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long [v3]
In-Reply-To: <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
 <V3YlichADWAeBYKYU-QF6VF9LWH-mfH5iPWP-l8EuRI=.e51d0b71-8368-46f1-a7a5-e2ac1940dc8d@github.com>
Message-ID: <TzyI4fRAHpWjZd75xC2rfbcjNfO5LtYEjroQOGDaEdg=.204bd58c-67fe-49e0-b3dd-ec691f2f8c0b@github.com>

On Wed, 22 Jun 2022 03:01:36 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Hi,
>> 
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comparison for direct value of compare

Thank you very much for your reviews

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From dnsimon at openjdk.org  Wed Jun 29 07:26:41 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 29 Jun 2022 07:26:41 GMT
Subject: RFR: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <adK9ZFKn9OnNuKQXM7mNJ06M7jAv0k-1VLLP77R5nNQ=.4c230cc7-c062-4db6-9b90-2ca616d120cf@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
 <adK9ZFKn9OnNuKQXM7mNJ06M7jAv0k-1VLLP77R5nNQ=.4c230cc7-c062-4db6-9b90-2ca616d120cf@github.com>
Message-ID: <R-SQDyx1hk9Bj3_JcGWrILMyzk9ouw5xEsD8U7XcbCo=.6865351e-b345-4aa4-a0af-9e4d4a622ed0@github.com>

On Tue, 28 Jun 2022 16:18:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
>> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
>> 2. SVM: Native to VM (enter SVM)
>> 3. SVM: VM to native (exit SVM)
>> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
>> 
>> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
>> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
>> 
>> There are other smaller changes to reduce JNI overhead included in this PR:
>> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
>> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
>> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
>> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
>> 
>> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.
>
> Seems fine.  Please add link to mach5 testing results to RFE.

Thanks @vnkozlov @dean-long and @dholmes-ora for the review. I'm doing a little more GraalVM testing before merging.

-------------

PR: https://git.openjdk.org/jdk/pull/9305

From duke at openjdk.org  Wed Jun 29 08:39:01 2022
From: duke at openjdk.org (Tongbao Zhang)
Date: Wed, 29 Jun 2022 08:39:01 GMT
Subject: RFR: 8289436: Make the redefine timer statistics more accurate
Message-ID: <0IXtkRmPFHL6LxPiSon40rtvEYfXwm1Ws4lC1WcoKIc=.0610468b-10a4-41f3-ab49-57e7890c2a4f@github.com>

Make the redefine timer statistics more accurate

-------------

Commit messages:
 - 8289436: Make the redefine timer statistics more accurate

Changes: https://git.openjdk.org/jdk/pull/9322/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9322&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289436
  Stats: 10 lines in 2 files changed: 8 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9322.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9322/head:pull/9322

PR: https://git.openjdk.org/jdk/pull/9322

From duke at openjdk.org  Wed Jun 29 10:37:06 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Wed, 29 Jun 2022 10:37:06 GMT
Subject: Integrated: 8283726: x86_64 intrinsics for compareUnsigned method in
 Integer and Long
In-Reply-To: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
References: <5VdXfCDIgQMXnjDWmtsd2dZ9lnGu9X-mOuSyWQqzDfI=.8aa5c0c6-ac1d-401c-9aa1-b82e49e4a98a@github.com>
Message-ID: <XjsZ5o4sg4nW0kEy8UHLlkhwfaMURUST2GXY1pJIV4I=.9c5e7d38-71b7-4042-b0d3-5fd60b47d098@github.com>

On Tue, 7 Jun 2022 17:14:18 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> Hi,
> 
> This patch implements intrinsics for `Integer/Long::compareUnsigned` using the same approach as the JVM does for long and floating-point comparisons. This allows efficient and reliable usage of unsigned comparison in Java, which is a basic operation and is important for range checks such as discussed in #8620 .
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: 108cd695
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/108cd695167f0eed7b778c29b55914998f15b90d
Stats:     271 lines in 15 files changed: 260 ins; 0 del; 11 mod

8283726: x86_64 intrinsics for compareUnsigned method in Integer and Long

Reviewed-by: kvn, jbhateja

-------------

PR: https://git.openjdk.org/jdk/pull/9068

From ngasson at openjdk.org  Wed Jun 29 11:27:44 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Wed, 29 Jun 2022 11:27:44 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter
In-Reply-To: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
Message-ID: <YqquGHMbn3EfzrluC7B-P_KefQ--6XHgPCgP8QsD0Q4=.bc4aba20-0d1b-4c8e-9ae4-523cecaf0f63@github.com>

On Wed, 22 Jun 2022 13:00:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

> There are several places in the interpreter that could be improved.
> 
> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 156:

> 154: REGISTER_DECLARATION(Register, esp,      r20);
> 155: // Sender's SP while in interpreter
> 156: REGISTER_DECLARATION(Register, r19_sender_sp, r19);

I don't think rmonitors above is used anywhere, perhaps you could reuse r25? Or at least delete the definition of rmonitors while you're editing this.

src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp line 98:

> 96:   void check_extended_sp(const char* msg = "check extended SP") {
> 97: #ifdef ASSERT
> 98:       Label L;

Should be two space indent here

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1430:

> 1428: 
> 1429:   // Restore SP (drop native parameters area), to keep SP in sync with extended_sp in frame
> 1430:   // __ restore_sp_after_call();

This seems to happen further down, around line 1530, but it's interleaved with popping the frame. Is there a reason to have the commented out call here?

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From stefank at openjdk.org  Wed Jun 29 12:07:54 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 29 Jun 2022 12:07:54 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v10]
In-Reply-To: <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
Message-ID: <YT5v8V6zI8nGSFXw_BoFVsxIyXO6t5Ma8uLXPw4nQmk=.ca045c56-f29f-41c5-a7f3-46e7937829e0@github.com>

On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - arg rename
>  - default arg
>  - revert
>  - fix-build

Marked as reviewed by stefank (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From coleen.phillimore at oracle.com  Wed Jun 29 12:18:45 2022
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 29 Jun 2022 08:18:45 -0400
Subject: Obsoleting JavaCritical
In-Reply-To: <0FDB5508-907A-466C-96D1-CD7AE5274DE8@oracle.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
 <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
 <20220607103108.900830823@eggemoggin.niobe.net>
 <cb7f4e85-6934-629a-d3d1-892dd3dc9b42@oracle.com>
 <0FDB5508-907A-466C-96D1-CD7AE5274DE8@oracle.com>
Message-ID: <12603c05-78a5-5e60-9c74-2b4ca780244f@oracle.com>



On 6/28/22 12:04 PM, Erik Osterlund wrote:
> Hi,
>
> Generational ZGC currently depends on CriticalJNINatives not existing, which was a valid move when it was removed. We didn?t anticipate it would suddenly come back from the dead. Ouch.

When we deprecated CriticalJNINatives, there were changes to remove the 
special GC code that blocked GC while this function is in native.? So it 
won't break Generational ZGC.
Thanks,
Coleen


>
> /Erik
>
>> On 28 Jun 2022, at 15:46, coleen.phillimore at oracle.com wrote:
>>
>> ?
>> Hi,
>>
>> I've filed https://bugs.openjdk.org/browse/JDK-8289302 to restore CriticalJNINatives until replacement intrinsics are found.
>>
>> Thanks,
>> Coleen
>>
>>> On 6/7/22 1:31 PM, mark.reinhold at oracle.com wrote:
>>> 2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>>>>> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>>>>> CLOCK_REALTIME.
>>>> Unfortunately System.currentTimeMillis() offers only millisecond
>>>> granularity which is the reason why our industry has to resort to
>>>> clock_gettime.
>>> If the platform included, say, an intrinsified System.nanoRealTime()
>>> method that returned clock_gettime(CLOCK_REALTIME), how much would
>>> that help developers in your unnamed industry?
>>>
>>> In a similar vein, if people are finding it necessary to ?replace parts
>>> of NIO with hand-crafted native code? then it would be interesting to
>>> understand what their requirements are.  Some simple enhancements to
>>> the NIO API would be much less costly to design and implement than a
>>> generalized user-level native-call intrinsification mechanism.
>>>
>>> - Mark


From coleenp at openjdk.org  Wed Jun 29 12:19:14 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 29 Jun 2022 12:19:14 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
Message-ID: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>

This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
This change also adds the deprecation message that was missed, which I checked is okay with the customer.

Tested with tiers1-4.

-------------

Commit messages:
 - Add deprecation message and test for CriticalJNINatives
 - 8289302: Restore CriticalJNINatives

Changes: https://git.openjdk.org/jdk19/pull/90/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=90&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289302
  Stats: 1350 lines in 18 files changed: 1172 ins; 0 del; 178 mod
  Patch: https://git.openjdk.org/jdk19/pull/90.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/90/head:pull/90

PR: https://git.openjdk.org/jdk19/pull/90

From duke at openjdk.org  Wed Jun 29 12:30:48 2022
From: duke at openjdk.org (duke)
Date: Wed, 29 Jun 2022 12:30:48 GMT
Subject: Withdrawn: 8285487: Do not generate trampolines for runtime calls if
 they are not needed
In-Reply-To: <vS-KesgpI9FACBR-SRyNyEe4DQpfn3-DrNuyHFCoJgE=.51e75851-3b69-487e-85f0-5b01551f014d@github.com>
References: <vS-KesgpI9FACBR-SRyNyEe4DQpfn3-DrNuyHFCoJgE=.51e75851-3b69-487e-85f0-5b01551f014d@github.com>
Message-ID: <gsdntG_WIUhZtlNMLs5r_HhHlctIRau_o4v826v3_GQ=.eff3a5f6-875d-41d0-8d3a-884f63077eb7@github.com>

On Tue, 26 Apr 2022 16:14:44 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases.
> 
> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed.
> 
> Testing:
> - `tier1`...`tier4`: Passed
> - `compiler/c2/aarch64/TestTrampoline.java`: Passed
> 
> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/8403

From ayang at openjdk.org  Wed Jun 29 13:15:56 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Jun 2022 13:15:56 GMT
Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v10]
In-Reply-To: <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
 <m3DEEYh2h6CSwusBiSleMY0MmEBgCdjhH9b7WAFFuE0=.27f19b0f-bc76-4505-84c8-01c3b1688743@github.com>
Message-ID: <fAoOmyPqmBDDdSIpI97GjOHdtPdZS6o2tAPD3Lx6oKk=.403fd23e-7c41-4f30-ba03-b7e2aaaf2c84@github.com>

On Tue, 28 Jun 2022 19:43:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename and some comments update.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - arg rename
>  - default arg
>  - revert
>  - fix-build

Thank you for the help and review.

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From ayang at openjdk.org  Wed Jun 29 13:18:02 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Jun 2022 13:18:02 GMT
Subject: Integrated: 8285364: Remove REF_ enum for java.lang.ref.Reference
In-Reply-To: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
References: <EvCA2lsVTa5kcc4G8z7w0hDOiL1hpSD4MxpSLzAgM0k=.daaeb476-b10b-438d-8d32-198d834f6c05@github.com>
Message-ID: <3WgU7S1tP7HNugSX-Wrw8J0FI8j0aZWmdYbnwWHsx4I=.c80e474d-101f-417a-905e-450bea6988e5@github.com>

On Thu, 21 Apr 2022 10:48:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple rename and some comments update.
> 
> Test: build

This pull request has now been integrated.

Changeset: 2961b7ee
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2961b7eede7205f8d67427bdf020de7966900424
Stats:     119 lines in 14 files changed: 74 ins; 35 del; 10 mod

8285364: Remove REF_ enum for java.lang.ref.Reference

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: kbarrett, coleenp, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/8332

From alanb at openjdk.org  Wed Jun 29 13:28:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Jun 2022 13:28:23 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
Message-ID: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>

This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.

The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

-------------

Commit messages:
 - Override can_support_virtual_threads description
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/82/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289278
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk19/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/82/head:pull/82

PR: https://git.openjdk.org/jdk19/pull/82

From sspitsyn at openjdk.org  Wed Jun 29 13:28:23 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Jun 2022 13:28:23 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <KaHDdw1Mz87oftfQnOJY5J6zxvSgL3I5WO9jt18WLI0=.9e344151-e393-4b58-ba81-178a2b0ca7f9@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/82

From rehn at openjdk.org  Wed Jun 29 13:38:51 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 29 Jun 2022 13:38:51 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
Message-ID: <pqoykpJzBk9CC-uioHlChPxaOhn3hvVEUGGRdGXegSw=.f7f67d52-6cfa-403d-9dbe-e749dfb71f51@github.com>

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

I'm not convinced.

The example provided for a short native call that is a lot slower is:
clock_gettime(CLOCK_REALTIME)

This is vDSO syscall, meaning it is just reading mapped memory.
If performance was essential why is the user not mapping the vDSO memory directly into Java, thus plainly reading without even needing to do a native method call?

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From coleenp at openjdk.org  Wed Jun 29 14:05:54 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 29 Jun 2022 14:05:54 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
Message-ID: <cRFtbH9dFsvE05HWWNzxg5C_aMI1JbU1AdFaCBckcrQ=.6e0a3229-db65-4b69-9f08-044ab378627b@github.com>

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

I assume it's because the user just wants to call clock_gettime(CLOCK_REALTIME) using the os API provided.

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From tholenstein at openjdk.org  Wed Jun 29 14:35:16 2022
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 29 Jun 2022 14:35:16 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2
 with -XX:+TracePhaseCCP
Message-ID: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>

`-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.

In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case

https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51

![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)

-------------

Commit messages:
 - updated assert message
 - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP

Changes: https://git.openjdk.org/jdk/pull/9295/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9295&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277060
  Stats: 74 lines in 3 files changed: 70 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9295.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9295/head:pull/9295

PR: https://git.openjdk.org/jdk/pull/9295

From rehn at openjdk.org  Wed Jun 29 14:35:43 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 29 Jun 2022 14:35:43 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
Message-ID: <9zSIirFg8J610ajhgylk47LMb-thNEb4Md15jCtLYvY=.13f7c552-9054-4f70-ab35-5c92968e2442@github.com>

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

Anyhow why not just add jrt leaf style calls (thread stays in Java, no transition) to our FFI story (with "hic sunt dracones" disclaimer) if this is something we need to support?
It should be pretty straight forward, at least for @JornVernee :)

What is the panama take on this?

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From duke at openjdk.org  Wed Jun 29 14:50:59 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Wed, 29 Jun 2022 14:50:59 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
Message-ID: <SEOOihMeBukAoQInq9Lt5xDYNB037oRdkZc8F9R4_FA=.793f18eb-4572-43d7-ad15-6cf09b27576a@github.com>

> ## Problem
> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
> 
> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
> 
> Each Java call has:
> - A relocation for a call site.
> - A relocation for a stub to the interpreter.
> - A stub to the interpreter.
> - If far jumps are used (arm64 case):
>   - A trampoline relocation.
>   - A trampoline.
> 
> We cannot avoid creating relocations. They are needed to support patching call sites.
> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
> If we try to generate relocations as we go there will be a case which requires negative offsets:
> 
> reloc1  ---> 0x0: stub1
> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
> 
> 
> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
> 
> ## Solution
> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
> 
> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
> 
> ## Results
> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
> - AArch64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      820544 |                       4592 |               18872 |
> | dec-tree         |      405280 |                       2580 |               22335 |
> | naive-bayes      |      392384 |                       2586 |               21184 |
> | log-regression   |      362208 |                       2450 |               20325 |
> | als              |      306048 |                       2226 |               18161 |
> | finagle-chirper  |      262304 |                       2087 |               12675 |
> | movie-lens       |      250112 |                       1937 |               13617 |
> | gauss-mix        |      173792 |                       1262 |               10304 |
> | finagle-http     |      164320 |                       1392 |               11269 |
> | page-rank        |      155424 |                       1175 |               10330 |
> | chi-square       |      140384 |                       1028 |                9480 |
> | akka-uct         |      115136 |                        541 |                3941 |
> | reactors         |       43264 |                        335 |                2503 |
> | scala-stm-bench7 |       42656 |                        326 |                3310 |
> | philosophers     |       36576 |                        256 |                2902 |
> | scala-doku       |       35008 |                        231 |                2695 |
> | rx-scrabble      |       32416 |                        273 |                2789 |
> | future-genetic   |       29408 |                        260 |                2339 |
> | scrabble         |       27968 |                        225 |                2477 |
> | par-mnemonics    |       19584 |                        168 |                1689 |
> | fj-kmeans        |       19296 |                        156 |                1647 |
> | scala-kmeans     |       18080 |                        140 |                1629 |
> | mnemonics        |       17408 |                        143 |                1512 |
> +------------------+-------------+----------------------------+---------------------+
> 
> - X86_64
> 
> +------------------+-------------+----------------------------+---------------------+
> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
> +------------------+-------------+----------------------------+---------------------+
> | dotty            |      337065 |                       4403 |               19135 |
> | dec-tree         |      183045 |                       2559 |               22071 |
> | naive-bayes      |      176460 |                       2450 |               19782 |
> | log-regression   |      162555 |                       2410 |               20648 |
> | als              |      121275 |                       1980 |               17179 |
> | movie-lens       |      111915 |                       1842 |               13020 |
> | finagle-chirper  |      106350 |                       1947 |               12726 |
> | gauss-mix        |       81975 |                       1251 |               10474 |
> | finagle-http     |       80895 |                       1523 |               12294 |
> | page-rank        |       68940 |                       1146 |               10124 |
> | chi-square       |       62130 |                        974 |                9315 |
> | akka-uct         |       50220 |                        555 |                4263 |
> | reactors         |       23385 |                        371 |                2544 |
> | philosophers     |       17625 |                        259 |                2865 |
> | scala-stm-bench7 |       17235 |                        295 |                3230 |
> | scala-doku       |       15600 |                        214 |                2698 |
> | rx-scrabble      |       14190 |                        262 |                2770 |
> | future-genetic   |       13155 |                        253 |                2318 |
> | scrabble         |       12300 |                        217 |                2352 |
> | fj-kmeans        |        8985 |                        157 |                1616 |
> | par-mnemonics    |        8535 |                        155 |                1684 |
> | scala-kmeans     |        8250 |                        138 |                1624 |
> | mnemonics        |        7485 |                        134 |                1522 |
> +------------------+-------------+----------------------------+---------------------+
> 
> 
> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
> - `tier1`...`tier4`: Passed
> - `hotspot/jtreg/compiler/sharedstubs`: Passed

Evgeny Astigeevich 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 20 additional commits since the last revision:

 - Merge branch 'master' into JDK-8280481C
 - Use call offset instead of caller pc
 - Simplify test
 - Fix x86 build failures
 - Remove UseSharedStubs and clarify shared stub use cases
 - Make SharedStubToInterpRequest ResourceObj and set initial size of SharedStubToInterpRequests to 8
 - Update copyright year and add Unimplemented guards
 - Set UseSharedStubs to true for X86
 - Set UseSharedStubs to true for AArch64
 - Fix x86 build failure
 - ... and 10 more: https://git.openjdk.org/jdk/compare/c88b2f38...da3bfb5b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8816/files
  - new: https://git.openjdk.org/jdk/pull/8816/files/a249f7da..da3bfb5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8816&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8816&range=00-01

  Stats: 183157 lines in 2793 files changed: 96216 ins; 65112 del; 21829 mod
  Patch: https://git.openjdk.org/jdk/pull/8816.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8816/head:pull/8816

PR: https://git.openjdk.org/jdk/pull/8816

From coleenp at openjdk.org  Wed Jun 29 15:05:45 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 29 Jun 2022 15:05:45 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
Message-ID: <R0NUWllsUg6DdRM8tRYvVmowivBuxmi0cRfL0biZ44k=.56fd4d5a-b20b-4988-88a8-a377dc797bb2@github.com>

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

Panama had this sort of functionality and didn't want to keep it. Hopefully they can answer.  They're working on satisfying the needs of this sort of customers, but until then, this is something that will prevent them from moving forward.

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From duke at openjdk.org  Wed Jun 29 15:06:43 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Wed, 29 Jun 2022 15:06:43 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
 <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
 <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
Message-ID: <dTBpnCm5rAIpCXTeJLX17iTRIRa3emWDwLCfTc_GT-8=.72010517-a8e8-4a89-96f1-b92148c7bff6@github.com>

On Tue, 28 Jun 2022 23:37:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> What I meant is that I will not submit my own testing until GitHub action testing is clean. Which is not which means something is wrong with changes: https://github.com/openjdk/jdk/pull/8816/checks?check_run_id=6998367114
> 
> Please, fix issues and update to latest JDK sources.

Sorry, my fault. I did not realise GHA is GitHub actions.
Linux x86 failures were caused by Loom project changes. Some x86 parts of the project have not been implemented yet. I updated to the latest JDK sources and they disappeared.
I am investigating macOS x64 failure.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From alanb at openjdk.org  Wed Jun 29 15:30:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Jun 2022 15:30:45 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
Message-ID: <Jt7n1dws6P9G7TYhxsWzZDf7zJm7WFieXn45j2oa94s=.12122a43-3658-4ce6-896a-1fdafe98df21@github.com>

On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality.  Customers are using this feature and there's no replacement yet for it.
> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag.
> This change also adds the deprecation message that was missed, which I checked is okay with the customer.
> 
> Tested with tiers1-4.

I would have liked to have seen more from the person that came to jdk-dev and panama-dev to complain about this. In particular, the mails mention replacing parts of NIO which suggests to me that this might be a JDK fork, or maybe the undocumented CriticalJNINative in conjunction with other dependences on JDK internals? It came across as completely unsupportable and I think engagement on panama-dev would be better before making any decision to bring this back.

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From mcimadamore at openjdk.org  Wed Jun 29 15:30:47 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 29 Jun 2022 15:30:47 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <9zSIirFg8J610ajhgylk47LMb-thNEb4Md15jCtLYvY=.13f7c552-9054-4f70-ab35-5c92968e2442@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
 <9zSIirFg8J610ajhgylk47LMb-thNEb4Md15jCtLYvY=.13f7c552-9054-4f70-ab35-5c92968e2442@github.com>
Message-ID: <m_8kyt66cFwEypdGytEq0CKI_ah5E8wAr4NVVncfVUA=.47fd68d1-0e2e-4fff-af1e-51431fcb574c@github.com>

On Wed, 29 Jun 2022 14:31:59 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> What is the panama take on this?

At some point Panama provided support for "trivial" calls, e.g. native calls whose Java -> native transition was elided. In more recent iterations of the API we ended up leaving that "feature" on the side: it only provided very limited boost (e.g. ~4-5 ns) and at great cost in terms of risks (e.g. if the native call upcalls back to Java a JVM crash is unavoidable).

As pointed out elsewhere [1, 2], a much better way to support this kind of use cases is through new intrinsics, as JVM intrinsics would avoid the typical costs associated with a native call (critical or not).

[1] - https://mail.openjdk.org/pipermail/panama-dev/2022-June/017048.html
[2] - https://mail.openjdk.org/pipermail/panama-dev/2022-June/017050.html

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From adinn at openjdk.org  Wed Jun 29 15:46:47 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jun 2022 15:46:47 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter
In-Reply-To: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
Message-ID: <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>

On Wed, 22 Jun 2022 13:00:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

> There are several places in the interpreter that could be improved.
> 
> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

A little bit of rework needed.

src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp line 176:

> 174:   int max_stack = method->constMethod()->max_stack() + MAX2(3, Method::extra_stack_entries());
> 175:   intptr_t* extended_sp = (intptr_t*) monbot  -
> 176:     (max_stack * Interpreter::stackElementWords) -

You are correctly multiplying by Interpreter::stackElementWords here. However, I noticed that at line 93 the multiply has been omitted

  int size = overhead +
         (callee_locals - callee_params) +
         monitors * frame::interpreter_frame_monitor_size() +

It should really follow x86 and include the multiply:

  int size = overhead +
         (callee_locals - callee_params) * Interpreter::stackElementWords +
         monitors * frame::interpreter_frame_monitor_size() +

We only get away with this because Interpreter::stackElementWords is 1.

Perhaps you could correct that as part of this patch?

src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp line 183:

> 181:   // All frames but the initial (oldest) interpreter frame we fill in have
> 182:   // a value for sender_sp that allows walking the stack but isn't
> 183:   // truly correct. Correct the value here.

The condition this comment leads into tests for

interpreter_frame->sender_sp() == interpreter_frame->interpreter_frame_sender_sp())

I'm not really clear how/where that actually happens? Can you explain?

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 607:

> 605:     DESCRIBE_FP_OFFSET(interpreter_frame_method);
> 606:     DESCRIBE_FP_OFFSET(interpreter_frame_mdp);
> 607:     DESCRIBE_FP_OFFSET(interpreter_frame_extended_sp);

Nothing wrong with adding this here but I notice you have not added `DESCRIBE_FP_OFFSET(interpreter_frame_extended_sp)` at line 679 in function `internal_pf()`. That function also fails to include `DESCRIBE_FP_OFFSET(interpreter_frame_mirror)`. Is this intended or accidental?

src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp line 188:

> 186:   }
> 187: 
> 188:   // r19_sender_sp: sender SP (must preserve; see prepare_to_jump_from_interpreted)

There are two other references to r13 that either need removing or fixing

286   Register temp3 = r14;  // r13 is live by this point: it contains the sender SP

and

356     // Live registers at this point:
357     //  member_reg - MemberName that was the trailing argument
358     //  temp1_recv_klass - klass of stacked receiver, if needed
359     //  r13 - interpreter linkage (if interpreted)  ??? FIXME
360     //  r1 ... r0 - compiler arguments (if compiled)

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 204:

> 202:     __ ldrd(v0, Address(esp, 2 * Interpreter::stackElementSize));
> 203:     __ ldrd(v1, Address(esp));
> 204:     __ mov(sp, r19_sender_sp);

Ok, finally a real bug! At line 200 we have

 200     __ mov(r19, lr);   <== this destroys sp in r19_sender_sp
 201     continuation = r19;


So, when you switch this from using `r13` to using `r19` here at line 204 you are effectively updating `sp` with `lr`.

Note this doesn't happen in the previous cases at line 193 because the assignments were done in the opposite order.

-------------

Changes requested by adinn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9239

From adinn at openjdk.org  Wed Jun 29 15:46:49 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 29 Jun 2022 15:46:49 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter
In-Reply-To: <YqquGHMbn3EfzrluC7B-P_KefQ--6XHgPCgP8QsD0Q4=.bc4aba20-0d1b-4c8e-9ae4-523cecaf0f63@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <YqquGHMbn3EfzrluC7B-P_KefQ--6XHgPCgP8QsD0Q4=.bc4aba20-0d1b-4c8e-9ae4-523cecaf0f63@github.com>
Message-ID: <fnS9noUSBMVQn1FxywGVUCa6SuxWnZBQc68RjqFnWEQ=.cbeaeec3-7e71-413e-810e-7cd59b13446f@github.com>

On Wed, 29 Jun 2022 11:23:54 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> There are several places in the interpreter that could be improved.
>> 
>> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
>> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
>> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1430:
> 
>> 1428: 
>> 1429:   // Restore SP (drop native parameters area), to keep SP in sync with extended_sp in frame
>> 1430:   // __ restore_sp_after_call();
> 
> This seems to happen further down, around line 1530, but it's interleaved with popping the frame. Is there a reason to have the commented out call here?

Ah, Nick got here before me. I also assume this needs to go.

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From dcubed at openjdk.org  Wed Jun 29 16:04:39 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 29 Jun 2022 16:04:39 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <hpEnqcvODlcxfAxor_HuRRvTw5KpxO_obz_-FDieswg=.19ada283-297e-49fc-8bf8-f05afb3e6d99@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/82

From dnsimon at openjdk.org  Wed Jun 29 16:17:30 2022
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 29 Jun 2022 16:17:30 GMT
Subject: Integrated: 8289094: [JVMCI] reduce JNI overhead and other VM rounds
 trips in JVMCI
In-Reply-To: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
References: <OYokZiEaQYupFsLG-kndDmdf6HlUmPfSV1b_D6d9syE=.03c11b07-93b3-4607-93c6-3687c88866c0@github.com>
Message-ID: <cwTWecJJkIGri351NsMuobRNVxe8LexZcbG4sGm3QCs=.d78232db-c392-46f4-8184-69c03bab52f3@github.com>

On Tue, 28 Jun 2022 07:46:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The interface between HotSpot and libjvmci is implemented via JNI. Every time HotSpot C++ code needs to access libjvmci objects, it requires 4 VM transitions:
> 1. HotSpot: VM to native (`_thread_in_vm` -> `_thread_in_native`)
> 2. SVM: Native to VM (enter SVM)
> 3. SVM: VM to native (exit SVM)
> 4. HotSpot: Native to VM (`_thread_in_native` -> `_thread_in_vm`)
> 
> When processing a `HotSpotCompiledCode` object during code installation (i.e. `CodeInstaller::install`), the overhead of all these transitions is significant.
> This PR changes the way code installation is done by serializing a `HotSpotCompiledCode` object to a byte array (in malloc'ed memory). The C++ code then deserializes this format to install the final code in the code cache. The bulk of this change is in `jdk.vm.ci.hotspot.HotSpotCompiledCodeStream` and `jvmciCodeInstaller.cpp`.
> 
> There are other smaller changes to reduce JNI overhead included in this PR:
> * Pass raw VM values alongside JVMCI wrapper objects to the VM to avoid JNI upcall to unbox in C++. For example, the [getBytecode](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java#L125) native method passed a `HotSpotResolvedJavaMethodImpl` to the VM and the VM then subsequently needs a JNI upcall to extract the `Method*` value from the `HotSpotResolvedJavaMethodImpl.methodHandle` field. With PR, `getBytecode` now passes an argument pair (i.e. `getBytecode(HotSpotResolvedJavaMethodImpl method, long methodPointer);`) that removes the unboxing upcall. This is done for all JVMCI objects that wrap a C++ object pointer. The box object is still passed as it protects the validity of the C++ pointer value.
> * Cache HotSpotConstantPool holder in [`HotSpotConstantPool.getHolder()`](https://github.com/openjdk/jdk/blob/33369719b2e39bddd4a1b7f300f36506306b03fa/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java#L236).
> * Remove VM round trip for converting a `Klass*` value to a `ResolvedJavaType`.
> * Avoid eager `String` creation in `JVMCIEnv::get_jvmci_type`.
> 
> This change is primarily in JVMCI-only code. It has been extensively tested in GraalVM on JDK 17. On the [octane](https://developers.google.com/octane) JavaScript benchmark, this PR reduces total time spent by GraalVM EE in JVMCI code installation from 648 s to 382 s.

This pull request has now been integrated.

Changeset: ba670ecb
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba670ecbb9efdbcaa783d4a933499ca191fb58c5
Stats:     4488 lines in 53 files changed: 2492 ins; 992 del; 1004 mod

8289094: [JVMCI] reduce JNI overhead and other VM rounds trips in JVMCI

Reviewed-by: kvn, dlong

-------------

PR: https://git.openjdk.org/jdk/pull/9305

From rehn at openjdk.org  Wed Jun 29 16:18:31 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 29 Jun 2022 16:18:31 GMT
Subject: RFR: 8286957: Held monitor count [v3]
In-Reply-To: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
Message-ID: <LF-d3oPI5b9Gmu7XCYKFW00WAmFuFH_o_m_LkKO4muA=.ef67ca1f-0bfd-42fc-bdbf-64309df96534@github.com>

> The current implementation do not count all monitor enter, counts high up in abstraction and causes a performance regression on aarch64 with some benchmarks due to C2 changes.
> 
> This change makes the counting exact by pushing the counting down in the abstraction.
> The additional JNI counter is strictly not needed, but enables us to figure out if we have monitors "on stack".
> 
> An uncontended lock plus unlock is 1 ns (21.5 -> 22.5) slower in C2 compiled code on x64 with the additional increment and decrement.
> 
> Fixed aarch64, x64, x86 and zero.
> 
> Passes t1-8

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Fixed var name
 - Merge branch 'master' into held-mon-count
 - Merge branch 'master' into held-mon-count
 - 8286957 - PR Baseline

-------------

Changes: https://git.openjdk.org/jdk/pull/8945/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8945&range=02
  Stats: 517 lines in 43 files changed: 301 ins; 143 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/8945.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8945/head:pull/8945

PR: https://git.openjdk.org/jdk/pull/8945

From rehn at openjdk.org  Wed Jun 29 16:18:32 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 29 Jun 2022 16:18:32 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <6L_IXz43fwMvolqBrhM40MANMz-CGrzh472MKEsHpuE=.0ac4e22d-c885-46b4-b78c-90441070473e@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
 <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
 <Bqtu6GeMH21JQbP7YBR2xTlhMZFwQ8o0KN_wuXsPqCM=.e23843f8-f031-4084-be9d-0cbbdeaaca0c@github.com>
 <6L_IXz43fwMvolqBrhM40MANMz-CGrzh472MKEsHpuE=.0ac4e22d-c885-46b4-b78c-90441070473e@github.com>
Message-ID: <PTzPxoLPWjDfkZ12iRQkSWWp7l_fOASsfLvXlOgfag8=.f9af54b6-a16c-4ed1-9907-7b61e69b9b70@github.com>

On Tue, 28 Jun 2022 12:39:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 629:
>> 
>>> 627:         mon->lock()->set_displaced_header(displaced);
>>> 628:         bool call_vm = UseHeavyMonitors;
>>> 629:         bool inc_mon_count = true;
>> 
>> Should be inc_mon**t**_count? We're consistent with `dec_mont_count`.
>
> Please do not use `mont` as an abbreviation for monitor - use `mon` or `monitor`. Thanks.

Thanks, fixed.

-------------

PR: https://git.openjdk.org/jdk/pull/8945

From rehn at openjdk.org  Wed Jun 29 16:18:32 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 29 Jun 2022 16:18:32 GMT
Subject: RFR: 8286957: Held monitor count [v2]
In-Reply-To: <qY-856kl2tBCY4AThIkzZUxBYC6xQX0ahlpw4qeIqjA=.e40ccdd7-18d0-41cf-8f9c-54ce7eeb21a6@github.com>
References: <mJCvlxn9EYK6pR481JLs2YvDopBHW4Y6BRdM6C_I5bs=.fa0813dd-27b6-4d58-b589-17ebe9d9def9@github.com>
 <vdYRHFkuf4gqLug171vs4cA-fS4e7OlQYC5KHvYQiX0=.5e7455b0-35d1-4cbd-ad6c-0b36a120e8ef@github.com>
 <qY-856kl2tBCY4AThIkzZUxBYC6xQX0ahlpw4qeIqjA=.e40ccdd7-18d0-41cf-8f9c-54ce7eeb21a6@github.com>
Message-ID: <zCX4SSJnXTmYnogjcXSegX49SGwL77-Ln3Oi3XaMMIk=.cb8a4ad3-e921-487e-8c30-8fc337b71656@github.com>

On Tue, 28 Jun 2022 12:30:04 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into held-mon-count
>>  - 8286957 - PR Baseline
>
> Marked as reviewed by rpressler (Author).

Thank you @pron !

-------------

PR: https://git.openjdk.org/jdk/pull/8945

From maurizio.cimadamore at oracle.com  Wed Jun 29 16:19:53 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 29 Jun 2022 17:19:53 +0100
Subject: Obsoleting JavaCritical
In-Reply-To: <CADV2yPkPgb3KH6BR=q4AUBMnXpojyKE8GdfM3rK46ZywV0rgGg@mail.gmail.com>
References: <CADV2yPkpOU+bmacahg1fgsJe9eO8YhWXyR792enQjxARNa2+kw@mail.gmail.com>
 <1c3e7789-f764-289e-dd0b-2f4f1b250acd@oracle.com>
 <CADV2yPkOaYoaB7GPJtmXyNQCaR7fO8Q9D0jsgvZ-S3LJ7cAjkA@mail.gmail.com>
 <04248465-fee4-20ba-c2a5-217d7867c6f4@oracle.com>
 <CADV2yPmoh54G7T-O3jibsQ9fNu2AcjDGJFSSOhBWiXFYA3dm-w@mail.gmail.com>
 <20220607103108.900830823@eggemoggin.niobe.net>
 <CADV2yPkPgb3KH6BR=q4AUBMnXpojyKE8GdfM3rK46ZywV0rgGg@mail.gmail.com>
Message-ID: <4857ff3a-eef5-d7ef-9cff-ff89441710a0@oracle.com>

Hi Wojciech,
picking up this thread again. After some internal discussion, we realize 
that we don't know enough about your use case. While re-enabling JNI 
critical would obviously provide a quick fix, we're afraid that (a) 
developers might end up depending on JNI critical when they don't need 
to (perhaps also unaware of the consequences of depending on it) and (b) 
that there might actually be _better_ (as in: much faster) solutions 
than using critical native calls to address at least some of your use 
cases (that seemed to be the case with the clock_gettime example you 
mentioned). Could you please provide a rough list of the native calls 
you make where you believe critical JNI is having a real impact in the 
performance of your application? Also, could you please tell us whether 
any of these calls need to interact with Java arrays? In other words, do 
you use critical JNI to remove the cost associated with thread 
transitions, or are you also taking advantage of accessing on-heap 
memory _directly_ from native code?

Regards
Maurizio

On 13/06/2022 21:38, Wojciech Kudla wrote:
> Hi Mark,
>
> Thanks for your input and apologies for the delayed response.
>
> > If the platform included, say, an intrinsified System.nanoRealTime()
> method that returned clock_gettime(CLOCK_REALTIME), how much would
> that help developers in your unnamed industry?
>
> Exposing realtime clock with nanosecond granularity in the JDK would 
> be a great step forward. I should have made it clear that I represent 
> fintech corner (investment banking to be exact) but the issues my 
> message touches upon span areas such as HPC, audio processing, gaming, 
> and defense industry so it's not like we have an isolated case.
>
> > In a similar vein, if people are finding it necessary to ?replace parts
> of NIO with hand-crafted native code? then it would be interesting to
> understand what their requirements are
>
> As for the other example I provided with making very short lived 
> syscalls such as recvmsg/recvmmsg the premise is getting access to 
> hardware timestamps on the ingress and egress ends as well as enabling 
> batch receive with a single syscall and otherwise exploiting features 
> unavailable from the JDK (like access to CMSG interface, 
> scatter/gather, etc).
> There are also other examples of calls that we'd love to make often 
> and at lowest possible cost (ie. getrusage) but I'm not sure if 
> there's a strong case for some of these ideas, that's why it might be 
> worth looking into more generic approach for performance sensitive code.
> Hope this does better job at explaining where we're coming from than 
> my previous messages.
>
> Thanks,
> W
>
> On Tue, Jun 7, 2022 at 6:31 PM <mark.reinhold at oracle.com> wrote:
>
>     2022/6/6 0:24:17 -0700, wkudla.kernel at gmail.com:
>     >> Yes for System.nanoTime(), but System.currentTimeMillis() reports
>     >> CLOCK_REALTIME.
>     >
>     > Unfortunately System.currentTimeMillis() offers only millisecond
>     > granularity which is the reason why our industry has to resort to
>     > clock_gettime.
>
>     If the platform included, say, an intrinsified System.nanoRealTime()
>     method that returned clock_gettime(CLOCK_REALTIME), how much would
>     that help developers in your unnamed industry?
>
>     In a similar vein, if people are finding it necessary to ?replace
>     parts
>     of NIO with hand-crafted native code? then it would be interesting to
>     understand what their requirements are.? Some simple enhancements to
>     the NIO API would be much less costly to design and implement than a
>     generalized user-level native-call intrinsification mechanism.
>
>     - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220629/870d5258/attachment.htm>

From sspitsyn at openjdk.org  Wed Jun 29 17:21:39 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 29 Jun 2022 17:21:39 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <m_nUyzhz4CyDJZr8ydbVy4PdbRQjaTXC2N1Pm-JAhZk=.1a2ad462-e123-453b-8f74-f07b97483202@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/82

From kvn at openjdk.org  Wed Jun 29 18:40:40 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 29 Jun 2022 18:40:40 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP
In-Reply-To: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
Message-ID: <OFik0VZ2TEqaNKROMkTZjO4YrJ092rAMIS37wJVOcZw=.abf629cc-bc6c-45fb-bbb1-f73f479763e8@github.com>

On Mon, 27 Jun 2022 08:45:19 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
> 
> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
> 
> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
> 
> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9295

From iklam at openjdk.org  Wed Jun 29 18:58:22 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Jun 2022 18:58:22 GMT
Subject: RFR: 8289231: Move java_lang_VirtualThread to
 continuationJavaClasses.hpp
In-Reply-To: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
References: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
Message-ID: <ZnqgPNoMr3IX6jQBgzBGbeVgOUK_83TkFirXfJBTlSQ=.812742ca-f9d8-4973-b753-5d450b56647a@github.com>

On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a follow up to [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623). `java_lang_VirtualThread` is part of loom and should be move to continuationJavaClasses.hpp, which contains the accessors for the other java classes used by loom.

Closing this PR. I might do a different patch to move all the thread related classes to somewhere like runtime/threadJavaClasses.hpp

-------------

PR: https://git.openjdk.org/jdk/pull/9298

From iklam at openjdk.org  Wed Jun 29 18:58:23 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 29 Jun 2022 18:58:23 GMT
Subject: Withdrawn: 8289231: Move java_lang_VirtualThread to
 continuationJavaClasses.hpp
In-Reply-To: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
References: <ys7d3a9ujC_NC09Et7BeXtlXzOcZfoO1X1ZQP7N-WhI=.4de94b39-d729-4380-ab5c-2d58122edcc7@github.com>
Message-ID: <00VCIS1HxTwYIFDeqWZb6Vl0GZyEm8CGdpq7MfnH0oM=.42c85cbc-68f4-4fc3-acbb-4df5a32ad358@github.com>

On Mon, 27 Jun 2022 19:13:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a follow up to [JDK-8288623](https://bugs.openjdk.org/browse/JDK-8288623). `java_lang_VirtualThread` is part of loom and should be move to continuationJavaClasses.hpp, which contains the accessors for the other java classes used by loom.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/9298

From dlong at openjdk.org  Wed Jun 29 20:06:40 2022
From: dlong at openjdk.org (Dean Long)
Date: Wed, 29 Jun 2022 20:06:40 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP
In-Reply-To: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
Message-ID: <PGrKcAMINIJJYVz4o5Nw9j_y3ga1kdLfotEJcHrqs9I=.99ee1d59-f51d-4c41-968f-8b3b534abf77@github.com>

On Mon, 27 Jun 2022 08:45:19 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
> 
> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
> 
> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
> 
> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)

src/hotspot/share/utilities/globalDefinitions.cpp line 326:

> 324: #ifdef ASSERT
> 325: int type2aelembytes(BasicType t, bool allow_address) {
> 326:   assert((allow_address || t != T_ADDRESS) && t != T_ILLEGAL, "unexpected basic type");

This is OK, but it only handles one possible bad value.  How about checking that t <= T_CONFLICT, or t < ARRAY_SIZE(__type2aelembytes)?

-------------

PR: https://git.openjdk.org/jdk/pull/9295

From duke at openjdk.org  Wed Jun 29 21:19:32 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Wed, 29 Jun 2022 21:19:32 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
 <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
 <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
Message-ID: <1aiCitX9Awl030q7myghYyOwZNfqJMIdCMmGm9jfoOQ=.2a5a7cd7-9e57-4538-8e22-7a9cf7523343@github.com>

On Tue, 28 Jun 2022 23:37:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> GHA testing is not clean.
>>> 
>>> I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.
>> 
>> Vladimir(@vnkozlov),
>> Have you got testing results?
>
>> > GHA testing is not clean.
>> > I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.
>> 
>> Vladimir(@vnkozlov), Have you got testing results?
> 
> What I meant is that I will not submit my own testing until GitHub action testing is clean. Which is not which means something is wrong with changes:
> https://github.com/openjdk/jdk/pull/8816/checks?check_run_id=6998367114
> 
> Please, fix issues and update to latest JDK sources.

@vnkozlov, with updating to the latest sources everything passed: https://github.com/eastig/jdk/actions/runs/2583924985

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From kvn at openjdk.org  Wed Jun 29 22:17:52 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 29 Jun 2022 22:17:52 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <SEOOihMeBukAoQInq9Lt5xDYNB037oRdkZc8F9R4_FA=.793f18eb-4572-43d7-ad15-6cf09b27576a@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <SEOOihMeBukAoQInq9Lt5xDYNB037oRdkZc8F9R4_FA=.793f18eb-4572-43d7-ad15-6cf09b27576a@github.com>
Message-ID: <mMQkDlyUOZshkPOJgDVF_h5QgRCW1Iusach1k-G8xnQ=.9d73b0ca-6631-43bc-a780-66c62ce1a308@github.com>

On Wed, 29 Jun 2022 14:50:59 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

>> ## Problem
>> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
>> 
>> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
>> 
>> Each Java call has:
>> - A relocation for a call site.
>> - A relocation for a stub to the interpreter.
>> - A stub to the interpreter.
>> - If far jumps are used (arm64 case):
>>   - A trampoline relocation.
>>   - A trampoline.
>> 
>> We cannot avoid creating relocations. They are needed to support patching call sites.
>> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
>> If we try to generate relocations as we go there will be a case which requires negative offsets:
>> 
>> reloc1  ---> 0x0: stub1
>> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
>> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
>> 
>> 
>> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
>> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
>> 
>> ## Solution
>> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
>> 
>> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
>> 
>> ## Results
>> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
>> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
>> - AArch64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      820544 |                       4592 |               18872 |
>> | dec-tree         |      405280 |                       2580 |               22335 |
>> | naive-bayes      |      392384 |                       2586 |               21184 |
>> | log-regression   |      362208 |                       2450 |               20325 |
>> | als              |      306048 |                       2226 |               18161 |
>> | finagle-chirper  |      262304 |                       2087 |               12675 |
>> | movie-lens       |      250112 |                       1937 |               13617 |
>> | gauss-mix        |      173792 |                       1262 |               10304 |
>> | finagle-http     |      164320 |                       1392 |               11269 |
>> | page-rank        |      155424 |                       1175 |               10330 |
>> | chi-square       |      140384 |                       1028 |                9480 |
>> | akka-uct         |      115136 |                        541 |                3941 |
>> | reactors         |       43264 |                        335 |                2503 |
>> | scala-stm-bench7 |       42656 |                        326 |                3310 |
>> | philosophers     |       36576 |                        256 |                2902 |
>> | scala-doku       |       35008 |                        231 |                2695 |
>> | rx-scrabble      |       32416 |                        273 |                2789 |
>> | future-genetic   |       29408 |                        260 |                2339 |
>> | scrabble         |       27968 |                        225 |                2477 |
>> | par-mnemonics    |       19584 |                        168 |                1689 |
>> | fj-kmeans        |       19296 |                        156 |                1647 |
>> | scala-kmeans     |       18080 |                        140 |                1629 |
>> | mnemonics        |       17408 |                        143 |                1512 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> - X86_64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      337065 |                       4403 |               19135 |
>> | dec-tree         |      183045 |                       2559 |               22071 |
>> | naive-bayes      |      176460 |                       2450 |               19782 |
>> | log-regression   |      162555 |                       2410 |               20648 |
>> | als              |      121275 |                       1980 |               17179 |
>> | movie-lens       |      111915 |                       1842 |               13020 |
>> | finagle-chirper  |      106350 |                       1947 |               12726 |
>> | gauss-mix        |       81975 |                       1251 |               10474 |
>> | finagle-http     |       80895 |                       1523 |               12294 |
>> | page-rank        |       68940 |                       1146 |               10124 |
>> | chi-square       |       62130 |                        974 |                9315 |
>> | akka-uct         |       50220 |                        555 |                4263 |
>> | reactors         |       23385 |                        371 |                2544 |
>> | philosophers     |       17625 |                        259 |                2865 |
>> | scala-stm-bench7 |       17235 |                        295 |                3230 |
>> | scala-doku       |       15600 |                        214 |                2698 |
>> | rx-scrabble      |       14190 |                        262 |                2770 |
>> | future-genetic   |       13155 |                        253 |                2318 |
>> | scrabble         |       12300 |                        217 |                2352 |
>> | fj-kmeans        |        8985 |                        157 |                1616 |
>> | par-mnemonics    |        8535 |                        155 |                1684 |
>> | scala-kmeans     |        8250 |                        138 |                1624 |
>> | mnemonics        |        7485 |                        134 |                1522 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> 
>> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
>> - `tier1`...`tier4`: Passed
>> - `hotspot/jtreg/compiler/sharedstubs`: Passed
>
> Evgeny Astigeevich 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8280481C
>  - Use call offset instead of caller pc
>  - Simplify test
>  - Fix x86 build failures
>  - Remove UseSharedStubs and clarify shared stub use cases
>  - Make SharedStubToInterpRequest ResourceObj and set initial size of SharedStubToInterpRequests to 8
>  - Update copyright year and add Unimplemented guards
>  - Set UseSharedStubs to true for X86
>  - Set UseSharedStubs to true for AArch64
>  - Fix x86 build failure
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/48ec70a5...da3bfb5b

Good. I submitted testing. Will let you know results.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From dholmes at openjdk.org  Thu Jun 30 02:48:47 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Jun 2022 02:48:47 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <wamTU_CT5g0K3678nnI_jZlim5AW9eJJBPAoZjTjRhs=.bafb457f-97bf-4426-b02a-39cebbd82e92@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/82

From kvn at openjdk.org  Thu Jun 30 03:06:46 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 30 Jun 2022 03:06:46 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <SEOOihMeBukAoQInq9Lt5xDYNB037oRdkZc8F9R4_FA=.793f18eb-4572-43d7-ad15-6cf09b27576a@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <SEOOihMeBukAoQInq9Lt5xDYNB037oRdkZc8F9R4_FA=.793f18eb-4572-43d7-ad15-6cf09b27576a@github.com>
Message-ID: <mMvyNu8rIwWBj_ixCKL_qh88jr7qsoTmkMsiwZNshIw=.163417fa-46ee-4255-b68c-5a81dc42e59c@github.com>

On Wed, 29 Jun 2022 14:50:59 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

>> ## Problem
>> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter.
>> 
>> Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides the address of the stub and the address of its owner. `relocInfo` has an offset which is an offset from the previously known relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset.
>> 
>> Each Java call has:
>> - A relocation for a call site.
>> - A relocation for a stub to the interpreter.
>> - A stub to the interpreter.
>> - If far jumps are used (arm64 case):
>>   - A trampoline relocation.
>>   - A trampoline.
>> 
>> We cannot avoid creating relocations. They are needed to support patching call sites.
>> With shared stubs there will be multiple relocations having the same stub address but different owners' addresses.
>> If we try to generate relocations as we go there will be a case which requires negative offsets:
>> 
>> reloc1  ---> 0x0: stub1
>> reloc2  ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4)
>> reloc3  ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4)
>> 
>> 
>> `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward.
>> Negative offsets reduce the offset range by half. This can increase filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them.
>> 
>> ## Solution
>> In this PR creation of stubs is done in two stages. First we collect requests for creating shared stubs: a callee `ciMethod*` and an offset of a call in `CodeBuffer` (see [src/hotspot/share/asm/codeBuffer.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae)). Then we have the finalisation phase (see [src/hotspot/share/ci/ciEnv.cpp](https://github.com/openjdk/jdk/pull/8816/files#diff-7c032de54e85754d39e080fd24d49b7469543b163f54229eb0631c6b1bf26450)), where `CodeBuffer::finalize_stubs()` creates shared stubs in `CodeBuffer`: a stub and multiple relocations sharing it. The first relocation will have positive offset. The rest will have zero offsets. This approach does not need negative offsets. As creation of relocations and stubs is platform dependent, `CodeBuffer::finalize_stubs()` calls `CodeBuffer::pd_finalize_stubs()` where platforms should put their code.
>> 
>> This PR provides implementations for x86, x86_64 and aarch64. [src/hotspot/share/asm/codeBuffer.inline.hpp](https://github.com/openjdk/jdk/pull/8816/files#diff-c268e3719578f2980edaa27c0eacbe9f620124310108eb65d0f765212c7042eb) provides the `emit_shared_stubs_to_interp` template which x86, x86_64 and aarch64 platforms use. Other platforms can use it too. Platforms supporting shared stubs to the interpreter must have `CodeBuffer::supports_shared_stubs()` returning `true`.
>> 
>> ## Results
>> **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)**
>> Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited.
>> - AArch64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      820544 |                       4592 |               18872 |
>> | dec-tree         |      405280 |                       2580 |               22335 |
>> | naive-bayes      |      392384 |                       2586 |               21184 |
>> | log-regression   |      362208 |                       2450 |               20325 |
>> | als              |      306048 |                       2226 |               18161 |
>> | finagle-chirper  |      262304 |                       2087 |               12675 |
>> | movie-lens       |      250112 |                       1937 |               13617 |
>> | gauss-mix        |      173792 |                       1262 |               10304 |
>> | finagle-http     |      164320 |                       1392 |               11269 |
>> | page-rank        |      155424 |                       1175 |               10330 |
>> | chi-square       |      140384 |                       1028 |                9480 |
>> | akka-uct         |      115136 |                        541 |                3941 |
>> | reactors         |       43264 |                        335 |                2503 |
>> | scala-stm-bench7 |       42656 |                        326 |                3310 |
>> | philosophers     |       36576 |                        256 |                2902 |
>> | scala-doku       |       35008 |                        231 |                2695 |
>> | rx-scrabble      |       32416 |                        273 |                2789 |
>> | future-genetic   |       29408 |                        260 |                2339 |
>> | scrabble         |       27968 |                        225 |                2477 |
>> | par-mnemonics    |       19584 |                        168 |                1689 |
>> | fj-kmeans        |       19296 |                        156 |                1647 |
>> | scala-kmeans     |       18080 |                        140 |                1629 |
>> | mnemonics        |       17408 |                        143 |                1512 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> - X86_64
>> 
>> +------------------+-------------+----------------------------+---------------------+
>> |    Benchmark     | Saved bytes | Nmethods with shared stubs | Final # of nmethods |
>> +------------------+-------------+----------------------------+---------------------+
>> | dotty            |      337065 |                       4403 |               19135 |
>> | dec-tree         |      183045 |                       2559 |               22071 |
>> | naive-bayes      |      176460 |                       2450 |               19782 |
>> | log-regression   |      162555 |                       2410 |               20648 |
>> | als              |      121275 |                       1980 |               17179 |
>> | movie-lens       |      111915 |                       1842 |               13020 |
>> | finagle-chirper  |      106350 |                       1947 |               12726 |
>> | gauss-mix        |       81975 |                       1251 |               10474 |
>> | finagle-http     |       80895 |                       1523 |               12294 |
>> | page-rank        |       68940 |                       1146 |               10124 |
>> | chi-square       |       62130 |                        974 |                9315 |
>> | akka-uct         |       50220 |                        555 |                4263 |
>> | reactors         |       23385 |                        371 |                2544 |
>> | philosophers     |       17625 |                        259 |                2865 |
>> | scala-stm-bench7 |       17235 |                        295 |                3230 |
>> | scala-doku       |       15600 |                        214 |                2698 |
>> | rx-scrabble      |       14190 |                        262 |                2770 |
>> | future-genetic   |       13155 |                        253 |                2318 |
>> | scrabble         |       12300 |                        217 |                2352 |
>> | fj-kmeans        |        8985 |                        157 |                1616 |
>> | par-mnemonics    |        8535 |                        155 |                1684 |
>> | scala-kmeans     |        8250 |                        138 |                1624 |
>> | mnemonics        |        7485 |                        134 |                1522 |
>> +------------------+-------------+----------------------------+---------------------+
>> 
>> 
>> **Testing: fastdebug and release builds for x86, x86_64 and aarch64**
>> - `tier1`...`tier4`: Passed
>> - `hotspot/jtreg/compiler/sharedstubs`: Passed
>
> Evgeny Astigeevich 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8280481C
>  - Use call offset instead of caller pc
>  - Simplify test
>  - Fix x86 build failures
>  - Remove UseSharedStubs and clarify shared stub use cases
>  - Make SharedStubToInterpRequest ResourceObj and set initial size of SharedStubToInterpRequests to 8
>  - Update copyright year and add Unimplemented guards
>  - Set UseSharedStubs to true for X86
>  - Set UseSharedStubs to true for AArch64
>  - Fix x86 build failure
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/e09644d9...da3bfb5b

Testing passed.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8816

From thomas.stuefe at gmail.com  Thu Jun 30 04:57:10 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 30 Jun 2022 06:57:10 +0200
Subject: Should we rename os:: functions that are named like standard C- or
 Posix-functions?
Message-ID: <CAA-vtUyQKAdwz+DaDYUZTDAYyijJcc_78rGd0Vhj1+aSm7oExg@mail.gmail.com>

Hi,

several functions in the os:: name scope are deliberately named like the
official counterparts they replace:

os::malloc, os::free, os::strdup, os::realloc, os::recv, os::send,
os::connect, os::signal...

There may be more. Some of them argument-match their counterparts (e.g.
os::free), while others don't.

Since the os:: variants can be called inside the os:: namespace with
omitting the leading os::, name confusions are possible. "free(p)" means
something different in global scope or inside an os:: function.

This can lead to problems that are difficult to find, e.g., mismatched
(os::)malloc->(os::)free with the potential to corrupt the C-heap:

https://bugs.openjdk.org/browse/JDK-8289477

And I remember having similar problems in the past. They don't happen
often, but if they do, they take some investigation time since they are
rarely obvious.

I discussed the above problem with the muslc devs
https://www.openwall.com/lists/musl/2022/06/29/3, and their position is
understandable that we should not use names of standard functions.

So I wonder if we should do that. Rename os::<function> to something like
os::<prefix><function>. And what the prefix or suffix would be.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220630/e17e018e/attachment.htm>

From david.holmes at oracle.com  Thu Jun 30 05:21:44 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jun 2022 15:21:44 +1000
Subject: Should we rename os:: functions that are named like standard C-
 or Posix-functions?
In-Reply-To: <CAA-vtUyQKAdwz+DaDYUZTDAYyijJcc_78rGd0Vhj1+aSm7oExg@mail.gmail.com>
References: <CAA-vtUyQKAdwz+DaDYUZTDAYyijJcc_78rGd0Vhj1+aSm7oExg@mail.gmail.com>
Message-ID: <6d8939d9-8f3e-6bd0-2e33-b54259a2d5a6@oracle.com>

Hi Thomas,

On 30/06/2022 2:57 pm, Thomas St?fe wrote:
> Hi,
> 
> several functions in the os:: name scope are deliberately named like the 
> official counterparts they replace:
> 
> os::malloc, os::free, os::strdup, os::realloc, os::recv, os::send, 
> os::connect,?os::signal...
> 
> There may be more. Some of them argument-match their counterparts (e.g. 
> os::free), while others don't.
> 
> Since the os:: variants can be called inside the os:: namespace with 
> omitting the leading os::, name confusions are possible. "free(p)" means 
> something different in global scope or inside an os:: function.
> 
> This can lead to problems that are difficult to find, e.g., mismatched 
> (os::)malloc->(os::)free with the potential to corrupt the C-heap:
> 
> https://bugs.openjdk.org/browse/JDK-8289477 
> <https://bugs.openjdk.org/browse/JDK-8289477>
> 
> And I remember having similar problems in the past. They don't happen 
> often, but if they do, they take some investigation time since they are 
> rarely obvious.
> 
> I discussed the above problem with the muslc devs 
> https://www.openwall.com/lists/musl/2022/06/29/3 
> <https://www.openwall.com/lists/musl/2022/06/29/3>, and their position 
> is understandable that we should not use names of standard functions.
> 
> So I wonder if we should do that. Rename os::<function> to something 
> like os::<prefix><function>. And what the prefix or suffix would be.

It annoys me that we have to do such things. It would have made more 
sense for the standard C library routines to have a prefix that marked 
them as reserved identifiers rather than polluting the global namespace 
the way they did. But no one thinks of these things initially and by the 
time it is standardised it is too late to make such changes. :(

I'm not sure this is a problem we have to address, but if we choose to 
then I think we should try to make a general improvement to the way os 
is used.

Maybe, as I think has been suggested before, we can move these out of 
the os class as they are not really about the os but the C library, and 
then any renaming that includes a prefix may not look so bad?

Maybe lib::C_free(), lib::C_malloc() etc?

Cheers,
David
-----

> Thanks, Thomas
> 

From thomas.stuefe at gmail.com  Thu Jun 30 06:36:23 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 30 Jun 2022 08:36:23 +0200
Subject: Should we rename os:: functions that are named like standard C-
 or Posix-functions?
In-Reply-To: <6d8939d9-8f3e-6bd0-2e33-b54259a2d5a6@oracle.com>
References: <CAA-vtUyQKAdwz+DaDYUZTDAYyijJcc_78rGd0Vhj1+aSm7oExg@mail.gmail.com>
 <6d8939d9-8f3e-6bd0-2e33-b54259a2d5a6@oracle.com>
Message-ID: <CAA-vtUxUpCxpuSPv9Ao6QBt5x_VfETipf33AV59kyE03Keo+XQ@mail.gmail.com>

On Thu, Jun 30, 2022 at 7:21 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 30/06/2022 2:57 pm, Thomas St?fe wrote:
> > Hi,
> >
> > several functions in the os:: name scope are deliberately named like the
> > official counterparts they replace:
> >
> > os::malloc, os::free, os::strdup, os::realloc, os::recv, os::send,
> > os::connect, os::signal...
> >
> > There may be more. Some of them argument-match their counterparts (e.g.
> > os::free), while others don't.
> >
> > Since the os:: variants can be called inside the os:: namespace with
> > omitting the leading os::, name confusions are possible. "free(p)" means
> > something different in global scope or inside an os:: function.
> >
> > This can lead to problems that are difficult to find, e.g., mismatched
> > (os::)malloc->(os::)free with the potential to corrupt the C-heap:
> >
> > https://bugs.openjdk.org/browse/JDK-8289477
> > <https://bugs.openjdk.org/browse/JDK-8289477>
> >
> > And I remember having similar problems in the past. They don't happen
> > often, but if they do, they take some investigation time since they are
> > rarely obvious.
> >
> > I discussed the above problem with the muslc devs
> > https://www.openwall.com/lists/musl/2022/06/29/3
> > <https://www.openwall.com/lists/musl/2022/06/29/3>, and their position
> > is understandable that we should not use names of standard functions.
> >
> > So I wonder if we should do that. Rename os::<function> to something
> > like os::<prefix><function>. And what the prefix or suffix would be.
>
> It annoys me that we have to do such things. It would have made more
> sense for the standard C library routines to have a prefix that marked
> them as reserved identifiers rather than polluting the global namespace
> the way they did. But no one thinks of these things initially and by the
> time it is standardised it is too late to make such changes. :(
>
>
I am not sure that would have helped. The original VM authors seemed to
deliberately duplicate the official names. Had the inventors of the
C-standard used a common prefix, we may have copied that too. But that's
ancient history, I don't know who introduced os:: and what their thoughts
were.


> I'm not sure this is a problem we have to address, but if we choose to
> then I think we should try to make a general improvement to the way os
> is used.
>
> Maybe, as I think has been suggested before, we can move these out of
> the os class as they are not really about the os but the C library, and
> then any renaming that includes a prefix may not look so bad?
>
> Maybe lib::C_free(), lib::C_malloc() etc?
>
>
I'd be fine with that. Other possibilities for such a namespace could be
"system" or permutations thereof, e.g. "sys::c_free()" etc. Avoids
discussions about what is a C-standard function, what is a Posix function,
etc.

Cheers, Thomas

Cheers,
> David
> -----
>
> > Thanks, Thomas
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220630/2d8c2894/attachment-0001.htm>

From tholenstein at openjdk.org  Thu Jun 30 07:14:36 2022
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Thu, 30 Jun 2022 07:14:36 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP [v2]
In-Reply-To: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
Message-ID: <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>

> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
> 
> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
> 
> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
> 
> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)

Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:

  stronger assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9295/files
  - new: https://git.openjdk.org/jdk/pull/9295/files/6605d161..da787818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9295&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9295&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9295.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9295/head:pull/9295

PR: https://git.openjdk.org/jdk/pull/9295

From tholenstein at openjdk.org  Thu Jun 30 07:14:39 2022
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Thu, 30 Jun 2022 07:14:39 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP [v2]
In-Reply-To: <PGrKcAMINIJJYVz4o5Nw9j_y3ga1kdLfotEJcHrqs9I=.99ee1d59-f51d-4c41-968f-8b3b534abf77@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
 <PGrKcAMINIJJYVz4o5Nw9j_y3ga1kdLfotEJcHrqs9I=.99ee1d59-f51d-4c41-968f-8b3b534abf77@github.com>
Message-ID: <2e-qlQjBB3kjIYfk4sxL_eOl23kEgwiQYa7dcsy-Gbg=.848388e1-b3b2-4c0d-b581-1e29a0ca58cd@github.com>

On Wed, 29 Jun 2022 20:02:38 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stronger assert
>
> src/hotspot/share/utilities/globalDefinitions.cpp line 326:
> 
>> 324: #ifdef ASSERT
>> 325: int type2aelembytes(BasicType t, bool allow_address) {
>> 326:   assert((allow_address || t != T_ADDRESS) && t != T_ILLEGAL, "unexpected basic type");
> 
> This is OK, but it only handles one possible bad value.  How about checking that t <= T_CONFLICT, or t < ARRAY_SIZE(__type2aelembytes)?

good point! I updated it

-------------

PR: https://git.openjdk.org/jdk/pull/9295

From iris at openjdk.org  Thu Jun 30 07:31:40 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 30 Jun 2022 07:31:40 GMT
Subject: [jdk19] RFR: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <U4wT25FNB2lr0YlSEMU7GNstxzDXnE2e9iV0kJHdvt4=.8fe3f2b7-614f-4445-baa6-fb1acd9f8480@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk19/pull/82

From jbhateja at openjdk.org  Thu Jun 30 08:48:25 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 30 Jun 2022 08:48:25 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <1aiCitX9Awl030q7myghYyOwZNfqJMIdCMmGm9jfoOQ=.2a5a7cd7-9e57-4538-8e22-7a9cf7523343@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
 <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
 <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
 <1aiCitX9Awl030q7myghYyOwZNfqJMIdCMmGm9jfoOQ=.2a5a7cd7-9e57-4538-8e22-7a9cf7523343@github.com>
Message-ID: <n6BA455Avixub7S_0T8rNOVc5595pX1Gfv4blv9J9pU=.de75ea89-2ee8-44a1-b012-788965ebe327@github.com>

On Wed, 29 Jun 2022 21:16:22 GMT, Evgeny Astigeevich <duke at openjdk.org> wrote:

>>> > GHA testing is not clean.
>>> > I looked through changes and they seem logically correct. Need more testing. I will wait when GHA is clean.
>>> 
>>> Vladimir(@vnkozlov), Have you got testing results?
>> 
>> What I meant is that I will not submit my own testing until GitHub action testing is clean. Which is not which means something is wrong with changes:
>> https://github.com/openjdk/jdk/pull/8816/checks?check_run_id=6998367114
>> 
>> Please, fix issues and update to latest JDK sources.
>
> @vnkozlov, with updating to the latest sources everything passed: https://github.com/eastig/jdk/actions/runs/2583924985

Hi @eastig ,
Are these memory saving shown on Renaissance with in-lining disabled ? 
Since static methods resolutions happen at compile time smaller methods may get inlined thus removing emission of stub. 

We are improving memory footprint of a method in code cache, does it also leads to some improvement in bench mark throughput by any means ?  

Once the code cache is full runtime attempts allocation extension if reserved code cache has space, followed by a [slow path of disabling the compilation.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeCache.cpp#L595) which may impact the performance.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From alanb at openjdk.org  Thu Jun 30 08:53:46 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Jun 2022 08:53:46 GMT
Subject: [jdk19] Integrated: 8289278: Suspend/ResumeAllVirtualThreads need both
 can_suspend and can_support_virtual_threads
In-Reply-To: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
References: <v0sq8MdGQ2aB2fhULxDsFV6fuWLtmdqlUp06nno9QTA=.62e4e807-1869-4ecd-b5c0-d90aacda5303@github.com>
Message-ID: <CkXWqxYjRvWvHfvvYOaAReF4040c3msob9aLmhHmGgU=.23fd93f1-04fb-4522-9c55-3fbcae123712@github.com>

On Tue, 28 Jun 2022 09:02:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is spec only change to the JVM TI spec. The `SuspendAllVirtualThreads` and `ResumeAllVirtualThreads` functions added in Java 19 currently specify that they require one of the capabilities `can_suspend` or `can_support_virtual_threads`. This is not correct as both capabilities are required.
> 
> The issue is in the XSL used to generate the spec, and specifically the `capabilities` template where it emits different text when the number of required capabilities is not 0 or 1. Additionally, the description of the `can_support_virtual_threads` is overridden in both functions to avoid making it appear that the capability on its own is needed to use these functions.

This pull request has now been integrated.

Changeset: c20b3aa9
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c20b3aa9c5ada4c87b3421fbc3290f4d6a4706ac
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and can_support_virtual_threads

Reviewed-by: sspitsyn, dcubed, dholmes, iris

-------------

PR: https://git.openjdk.org/jdk19/pull/82

From aph at openjdk.org  Thu Jun 30 09:13:38 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 09:13:38 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter
In-Reply-To: <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
Message-ID: <AsswTm_L5g-asenZ1H2QLlP5t5uR47yh-bz0UpdiDpY=.3a9555c2-1cc3-4d92-9777-b1d160081c1d@github.com>

On Wed, 29 Jun 2022 15:41:27 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> There are several places in the interpreter that could be improved.
>> 
>> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
>> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
>> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 204:
> 
>> 202:     __ ldrd(v0, Address(esp, 2 * Interpreter::stackElementSize));
>> 203:     __ ldrd(v1, Address(esp));
>> 204:     __ mov(sp, r19_sender_sp);
> 
> Ok, finally a real bug! At line 200 we have
> 
>  200     __ mov(r19, lr);   <== this destroys sp in r19_sender_sp
>  201     continuation = r19;
> 
> 
> So, when you switch this from using `r13` to using `r19` here at line 204 you are effectively updating `sp` with `lr`.
> 
> Note this doesn't happen in the previous cases at line 193 because the assignments were done in the opposite order.

Aha!

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From aph at openjdk.org  Thu Jun 30 09:47:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 09:47:15 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
Message-ID: <Vc-N96JOG2QfZAwHhSzIIPwij1rHVmd22sCeWAGqpBU=.6dd4e466-76b7-465c-9cec-073bdae3b56e@github.com>

> There are several places in the interpreter that could be improved.
> 
> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - 8288971: AArch64: Clean up stack and register handling in interpreter
 - 8288971: AArch64: Clean up stack and register handling in interpreter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9239/files
  - new: https://git.openjdk.org/jdk/pull/9239/files/3e5b9e1d..bf56b389

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=00-01

  Stats: 26 lines in 7 files changed: 2 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/9239.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9239/head:pull/9239

PR: https://git.openjdk.org/jdk/pull/9239

From aph at openjdk.org  Thu Jun 30 09:47:15 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 09:47:15 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
Message-ID: <GYvppbHgvUdp40Awgi5ngdaBzMnhrttdXs96VDvWRWw=.21bf4503-dcf4-485f-b00d-74fbc75c22e3@github.com>

On Wed, 29 Jun 2022 15:25:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>
> src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp line 176:
> 
>> 174:   int max_stack = method->constMethod()->max_stack() + MAX2(3, Method::extra_stack_entries());
>> 175:   intptr_t* extended_sp = (intptr_t*) monbot  -
>> 176:     (max_stack * Interpreter::stackElementWords) -
> 
> You are correctly multiplying by Interpreter::stackElementWords here. However, I noticed that at line 93 the multiply has been omitted
> 
>   int size = overhead +
>          (callee_locals - callee_params) +
>          monitors * frame::interpreter_frame_monitor_size() +
> 
> It should really follow x86 and include the multiply:
> 
>   int size = overhead +
>          (callee_locals - callee_params) * Interpreter::stackElementWords +
>          monitors * frame::interpreter_frame_monitor_size() +
> 
> We only get away with this because Interpreter::stackElementWords is 1.
> 
> Perhaps you could correct that as part of this patch?

OK, done. Ta.

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From adinn at openjdk.org  Thu Jun 30 10:04:39 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jun 2022 10:04:39 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <Vc-N96JOG2QfZAwHhSzIIPwij1rHVmd22sCeWAGqpBU=.6dd4e466-76b7-465c-9cec-073bdae3b56e@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <Vc-N96JOG2QfZAwHhSzIIPwij1rHVmd22sCeWAGqpBU=.6dd4e466-76b7-465c-9cec-073bdae3b56e@github.com>
Message-ID: <JZbZKGpSnP_7QbpTnsOB6TPa8zwejQJVEYQF18qYCP4=.bc1b0e91-7efd-41fb-b491-391803c7e8fe@github.com>

On Thu, 30 Jun 2022 09:47:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There are several places in the interpreter that could be improved.
>> 
>> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
>> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
>> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>  - 8288971: AArch64: Clean up stack and register handling in interpreter

All good.

-------------

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9239

From thartmann at openjdk.org  Thu Jun 30 10:40:43 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 30 Jun 2022 10:40:43 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP [v2]
In-Reply-To: <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
 <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
Message-ID: <DrkqGZt6uphPVifQkQYARPfmll3Vd9cN4RkGCVcrTs8=.0be1f35f-9828-48fb-bd86-0d0f4c0f39ec@github.com>

On Thu, 30 Jun 2022 07:14:36 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
>> 
>> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
>> 
>> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
>> 
>> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stronger assert

Looks good to me!

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9295

From aph at openjdk.org  Thu Jun 30 10:41:41 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 10:41:41 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
Message-ID: <AACFwZIGdOuBmvcI085dUT8YUKqCpsgMs2pT5FhR4XM=.422f9b30-680b-4184-9b9e-e5321ffe0458@github.com>

On Wed, 29 Jun 2022 15:28:44 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>
> src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp line 183:
> 
>> 181:   // All frames but the initial (oldest) interpreter frame we fill in have
>> 182:   // a value for sender_sp that allows walking the stack but isn't
>> 183:   // truly correct. Correct the value here.
> 
> The condition this comment leads into tests for
> 
> interpreter_frame->sender_sp() == interpreter_frame->interpreter_frame_sender_sp())
> 
> I'm not really clear how/where that actually happens? Can you explain?

Sure.
First thing to realize is that this method is used only by deopt. The logic here removes the caller's args that it's pushed onto the stack, iff the caller is an interpreted method.
I think this is a hangover from x86. It doesn't hurt, but neither does it do anything useful AFAICS because we're going to restore the caller's SP from `interpreter_frame_extended_sp` and the caller's ESP from `interpreter_frame_last_sp` as soon as we return.
I guess it's possible that something somewhere that walks the stack depends on this logic, but if it does I can't find it.

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From adinn at openjdk.org  Thu Jun 30 10:57:31 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 30 Jun 2022 10:57:31 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <AACFwZIGdOuBmvcI085dUT8YUKqCpsgMs2pT5FhR4XM=.422f9b30-680b-4184-9b9e-e5321ffe0458@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <WbOejLI3qFsFOLOx3gwIT5tlW5iH-RRS_E_hLDxvErw=.4976439e-da80-4771-9ad7-58e8c5e435e1@github.com>
 <AACFwZIGdOuBmvcI085dUT8YUKqCpsgMs2pT5FhR4XM=.422f9b30-680b-4184-9b9e-e5321ffe0458@github.com>
Message-ID: <Ruai6s_YHIpho7G4hUw_-V8qgekbuHiFQWqumkbTfqk=.b94cb911-56b1-4841-b03f-bcd478a1446f@github.com>

On Thu, 30 Jun 2022 10:37:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/abstractInterpreter_aarch64.cpp line 183:
>> 
>>> 181:   // All frames but the initial (oldest) interpreter frame we fill in have
>>> 182:   // a value for sender_sp that allows walking the stack but isn't
>>> 183:   // truly correct. Correct the value here.
>> 
>> The condition this comment leads into tests for
>> 
>> interpreter_frame->sender_sp() == interpreter_frame->interpreter_frame_sender_sp())
>> 
>> I'm not really clear how/where that actually happens? Can you explain?
>
> Sure.
> First thing to realize is that this method is used only by deopt. The logic here removes the caller's args that it's pushed onto the stack, iff the caller is an interpreted method.
> I think this is a hangover from x86. It doesn't hurt, but neither does it do anything useful AFAICS because we're going to restore the caller's SP from `interpreter_frame_extended_sp` and the caller's ESP from `interpreter_frame_last_sp` as soon as we return.
> I guess it's possible that something somewhere that walks the stack depends on this logic, but if it does I can't find it.

Ah yes, I should have looked at the calling code. Ta!

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From ngasson at openjdk.org  Thu Jun 30 11:11:40 2022
From: ngasson at openjdk.org (Nick Gasson)
Date: Thu, 30 Jun 2022 11:11:40 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v2]
In-Reply-To: <Vc-N96JOG2QfZAwHhSzIIPwij1rHVmd22sCeWAGqpBU=.6dd4e466-76b7-465c-9cec-073bdae3b56e@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
 <Vc-N96JOG2QfZAwHhSzIIPwij1rHVmd22sCeWAGqpBU=.6dd4e466-76b7-465c-9cec-073bdae3b56e@github.com>
Message-ID: <_CfjJQkC040IqcOIaZL44QMrH2-eNXDFRYb6ZXX2rtw=.344861df-59f7-4a16-bc8e-f7ffad2434cd@github.com>

On Thu, 30 Jun 2022 09:47:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There are several places in the interpreter that could be improved.
>> 
>> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
>> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
>> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8288971: AArch64: Clean up stack and register handling in interpreter
>  - 8288971: AArch64: Clean up stack and register handling in interpreter

Marked as reviewed by ngasson (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9239

From chagedorn at openjdk.org  Thu Jun 30 12:18:41 2022
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 30 Jun 2022 12:18:41 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP [v2]
In-Reply-To: <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
 <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
Message-ID: <EipoqTLZVDh_ftMG4H3M5MQI2HZsj1ZBCVaaJNvrUc8=.8d02a204-09e7-4027-a72c-e1366d433144@github.com>

On Thu, 30 Jun 2022 07:14:36 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
>> 
>> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
>> 
>> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
>> 
>> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stronger assert

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9295

From ayang at openjdk.org  Thu Jun 30 12:19:04 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jun 2022 12:19:04 GMT
Subject: RFR: 8289520: G1: Remove duplicate checks in
 G1BarrierSetC1::post_barrier
Message-ID: <3MnSORD3lOo4Et75TBnD9Y6RmysHMi07QUBKT3mqcsY=.554293bc-0a11-483c-b9c6-b6bc25313223@github.com>

Simple change of removing effectively dead code.

Test: tier1-3

-------------

Commit messages:
 - g1-post-barrier

Changes: https://git.openjdk.org/jdk/pull/9333/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9333&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289520
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9333.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9333/head:pull/9333

PR: https://git.openjdk.org/jdk/pull/9333

From tschatzl at openjdk.org  Thu Jun 30 13:15:39 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Jun 2022 13:15:39 GMT
Subject: RFR: 8289520: G1: Remove duplicate checks in
 G1BarrierSetC1::post_barrier
In-Reply-To: <3MnSORD3lOo4Et75TBnD9Y6RmysHMi07QUBKT3mqcsY=.554293bc-0a11-483c-b9c6-b6bc25313223@github.com>
References: <3MnSORD3lOo4Et75TBnD9Y6RmysHMi07QUBKT3mqcsY=.554293bc-0a11-483c-b9c6-b6bc25313223@github.com>
Message-ID: <um4pHR6AGkyyYG7ixFZw-6OgIhhGoVqsrAOhsE5mEQg=.3e018942-2de3-4434-aed3-267337aade33@github.com>

On Thu, 30 Jun 2022 12:08:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: tier1-3

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9333

From mbaesken at openjdk.org  Thu Jun 30 13:25:18 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Jun 2022 13:25:18 GMT
Subject: RFR: JDK-8289524: Add JFR JIT restart event
Message-ID: <TD--iJ0w5WYNpQmuBxrLH3lt23Ymb5sy5uiY2CT3LQQ=.d4cfaaf8-6650-453e-8cf0-dc8211c3cb34@github.com>

The JIT compiler restarts (see restart_compiler in NMethodSweeper::sweep_code_cache) would be a helpful addition to the JFR events. Currently we log the JIT stop operations in JFR (EventCodeCacheFull) but no restart.

-------------

Commit messages:
 - JDK-8289524

Changes: https://git.openjdk.org/jdk/pull/9334/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9334&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289524
  Stats: 21 lines in 6 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9334.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9334/head:pull/9334

PR: https://git.openjdk.org/jdk/pull/9334

From mdoerr at openjdk.org  Thu Jun 30 13:25:43 2022
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 30 Jun 2022 13:25:43 GMT
Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives
In-Reply-To: <m_8kyt66cFwEypdGytEq0CKI_ah5E8wAr4NVVncfVUA=.47fd68d1-0e2e-4fff-af1e-51431fcb574c@github.com>
References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com>
 <9zSIirFg8J610ajhgylk47LMb-thNEb4Md15jCtLYvY=.13f7c552-9054-4f70-ab35-5c92968e2442@github.com>
 <m_8kyt66cFwEypdGytEq0CKI_ah5E8wAr4NVVncfVUA=.47fd68d1-0e2e-4fff-af1e-51431fcb574c@github.com>
Message-ID: <S7XH3G0JEuKuMgkILYLWwxEmz7pUj-Uvb7OcmKwhkVg=.97378cf5-f22a-41a4-9979-c8958ac89d91@github.com>

On Wed, 29 Jun 2022 15:27:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > What is the panama take on this?
> 
> At some point Panama provided support for "trivial" calls, e.g. native calls whose Java -> native transition was elided. In more recent iterations of the API we ended up leaving that "feature" on the side: it only provided very limited boost (e.g. ~4-5 ns) and at great cost in terms of risks (e.g. if the native call upcalls back to Java a JVM crash is unavoidable).
> 
> As pointed out elsewhere [1, 2], a much better way to support this kind of use cases is through new intrinsics, as JVM intrinsics would avoid the typical costs associated with a native call (critical or not).
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2022-June/017048.html [2] - https://mail.openjdk.org/pipermail/panama-dev/2022-June/017050.html

Did you check the performance boost on a multi-socket machine? Impact is significantly larger than on single-chip systems. We had experimented with CriticalJNINatives on large x86_64 and ppc64 servers.

-------------

PR: https://git.openjdk.org/jdk19/pull/90

From aph at openjdk.org  Thu Jun 30 15:06:43 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 15:06:43 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v3]
In-Reply-To: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
Message-ID: <XNrHlz9T7tXSN3hGwzIPrYXrkBfUaZ1PTK1Xpuj7X9s=.b13f86e0-cc28-40c2-9a44-845a2cb84ac3@github.com>

> There are several places in the interpreter that could be improved.
> 
> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Update templateInterpreterGenerator_aarch64.cpp
 - Update assembler_aarch64.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9239/files
  - new: https://git.openjdk.org/jdk/pull/9239/files/bf56b389..b9d7186c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9239.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9239/head:pull/9239

PR: https://git.openjdk.org/jdk/pull/9239

From aph at openjdk.org  Thu Jun 30 15:14:29 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 15:14:29 GMT
Subject: RFR: 8288971: AArch64: Clean up stack and register handling in
 interpreter [v4]
In-Reply-To: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
References: <g3dxOogHalA2876nNxf3ZX5vA873Vmi11CCVxpi6Nxk=.a5754605-e4a2-4cab-970d-392b5a678a07@github.com>
Message-ID: <hwHQ0ZerA7DStUeKI8RA28txZP2Mb8OfusyiLVxwOws=.d7d574cd-7c4e-4fb6-9d31-931c49c6db96@github.com>

> There are several places in the interpreter that could be improved.
> 
> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Update templateInterpreterGenerator_aarch64.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9239/files
  - new: https://git.openjdk.org/jdk/pull/9239/files/b9d7186c..7c4346c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9239&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9239.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9239/head:pull/9239

PR: https://git.openjdk.org/jdk/pull/9239

From hseigel at openjdk.org  Thu Jun 30 18:47:05 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Thu, 30 Jun 2022 18:47:05 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
Message-ID: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>

Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.

Thanks, Harold

-------------

Commit messages:
 - 8289534: Change 'uncomplicated' hotspot runtime options

Changes: https://git.openjdk.org/jdk/pull/9338/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289534
  Stats: 42 lines in 10 files changed: 1 ins; 0 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/9338.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9338/head:pull/9338

PR: https://git.openjdk.org/jdk/pull/9338

From dlong at openjdk.org  Thu Jun 30 19:57:43 2022
From: dlong at openjdk.org (Dean Long)
Date: Thu, 30 Jun 2022 19:57:43 GMT
Subject: RFR: JDK-8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in
 TypeAryPtr::dump2 with -XX:+TracePhaseCCP [v2]
In-Reply-To: <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
References: <HmnY56rFKYMO-QBAy4M6QL3kW_ily_eY6Uznawwdg4c=.f3fecfbb-e100-4f1c-b2b0-de06225f3620@github.com>
 <Oifq_uuCi2EMDrrShigh5o89A41TyxaLIxAZOhNEU6k=.e8b5f50c-3988-4bd4-a4de-6d59820ee0b9@github.com>
Message-ID: <9X5r2mRhnR3fV9rKU2yNdPNCc3uzTO3xE4bQ9Uj5xH0=.6c62a6a9-a6df-4dff-98d7-b1162b9d6cf2@github.com>

On Thu, 30 Jun 2022 07:14:36 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> `-XX:+TracePhaseCCP`fails in `TypeAryPtr::dump2` when `_offset` >= `header_size` and the basic type of the array element (`elem()->basic_type()`) is `T_ILLEGAL`: This case needs to be handled separately and print `+any`. Otherwise calling `type2aelembytes(T_ILLEGAL)` would lead to an out of array access because `T_ILLEGAL` has int value 99 and `_type2aelembytes[]` only has size 20. That `type2aelembytes(T_ILLEGAL)` returns zero and therefore triggers the `EXCEPTION_INT_DIVIDE_BY_ZERO` was luck. Therefore an assert was added to `type2aelembytes` to catch out-of bound accesses.
>> 
>> In the test case node `827 CMoveP` has base type `T_ILLEGAL` because `elem()->base()`  is `Type::Bottom`. Normally an array would have either type `int[]` or `long[]`. Because we assign it to `Object`, the `Object` has type `bottom[int:1]:NotNull` because the is no common supertype of `long[int:1]:NotNull:exact` and `int[int:1]:NotNull:exact`. In normal Java we could not copy the `Object srcArrLocal ` to `int[] dstArr`, because we would need to access `srcArrLocal[]` which is not possible for `Object` - But using `UNSAFE.copyMemory` this is allowed. Therefore the printing code has to be adjusted to support this case
>> 
>> https://github.com/openjdk/jdk/blob/6605d1614db2de302ebaf90863dcd2585b5c27ba/test/hotspot/jtreg/compiler/debug/TestTracePhaseCCP.java#L49-L51
>> 
>> ![T_ILLEGAL](https://user-images.githubusercontent.com/71546117/176450705-12d4dc5c-f80d-4a7f-ae60-d71ddd089678.png)
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stronger assert

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9295

From coleenp at openjdk.org  Thu Jun 30 20:01:51 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 30 Jun 2022 20:01:51 GMT
Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options
In-Reply-To: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
References: <NJ77oyBr1A8G8cb0A38XmG8Nk_TJbvK3mB9l_cSeaiw=.ba56834b-d5de-4994-8621-b1d6d67567da@github.com>
Message-ID: <QiqgG29zeLP_czhaTGLdNJM1WTLKgwVGUTPfs7vgCDg=.d6d1e705-a67d-4e7f-b65a-40bc4de329c8@github.com>

On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits.  This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9338

From duke at openjdk.org  Thu Jun 30 21:29:39 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 30 Jun 2022 21:29:39 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
 [v2]
In-Reply-To: <n6BA455Avixub7S_0T8rNOVc5595pX1Gfv4blv9J9pU=.de75ea89-2ee8-44a1-b012-788965ebe327@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <IXOeeBwYTwbz5xrP9_kuGi7XBeMUBFgHM5G-Fo6BPbw=.0ad8e378-64af-4515-86f3-7c79a819e026@github.com>
 <G5euD8cnHTCswD9AWGM5m7A-2CuQtF0Ioytj2uPr0EM=.9d08c127-6b66-4ec7-87c3-734b44441cbe@github.com>
 <BEidvG6uKSzWn6RYp_NwP3nqCG_yrttc4tMJIqKZve4=.3f0dbdb5-4c16-48d7-80ac-ca2015315f15@github.com>
 <oSFcwwSNHMt9hTUMjS26EGlJAmH-zZXhwEqsMhM0EAI=.cc40824d-293f-4ffb-b1a5-4f0e27c72bae@github.com>
 <1aiCitX9Awl030q7myghYyOwZNfqJMIdCMmGm9jfoOQ=.2a5a7cd7-9e57-4538-8e22-7a9cf7523343@github.com>
 <n6BA455Avixub7S_0T8rNOVc5595pX1Gfv4blv9J9pU=.de75ea89-2ee8-44a1-b012-788965ebe327@github.com>
Message-ID: <XmsgDzL5YbYTVQmyQaymrHfsYIoBYACyD9ylohtje50=.f12a48cd-41e8-46d3-a036-a4e05d8ab566@github.com>

On Thu, 30 Jun 2022 08:45:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @vnkozlov, with updating to the latest sources everything passed: https://github.com/eastig/jdk/actions/runs/2583924985
>
> Hi @eastig ,
> Are these memory saving shown on Renaissance with in-lining disabled ? 
> Since static methods resolutions happen at compile time smaller methods may get inlined thus removing emission of stub. 
> 
> We are improving memory footprint of a method in code cache, does it also leads to some improvement in bench mark throughput by any means ?  
> 
> Once the code cache is full runtime attempts allocation extension if reserved code cache has space, followed by a [slow path of disabling the compilation.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeCache.cpp#L595) which may impact the performance.

Hi @jatin-bhateja,

> Are these memory saving shown on Renaissance with in-lining disabled ?

Except the Java heap size tuning, JVM was run in the default configuration. No changes to inlining were done.

> Since static methods resolutions happen at compile time smaller methods may get inlined thus removing emission of stub.

You are correct. You can see this in data: the total number of nmethods with shared stubs. For arm64 a stub to the interpreter is 8 instructions. For x86 it is just 3 instructions: mov, jmp and nop. Or in terms of code size: 32 bytes arm64 vs 16 bytes x86. Arm64 gets more benefits from the patch than x86.

> We are improving memory footprint of a method in code cache, does it also leads to some improvement in bench mark throughput by any means ?

There are a few patches, including this one, which improve memory footprint of a method, each of them separately does not show much performance improvement. However all together they demonstrate performance improvements, especially in benchmarks with tens of thousands of methods. For example DaCapo eclipse shows ~4% improvements on arm64.

> Once the code cache is full runtime attempts allocation extension if reserved code cache has space, followed by a [slow path of disabling the compilation.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/codeCache.cpp#L595) which may impact the performance.

It's even worse than this. Andrew mentioned CodeCache trashing in PR to change the default CodeCache size from 240M to 127 for arm64. With CodeCache trashing compilation does not stop. You constantly throw away compiled code, jump to the interpreter, recompile and jump to the newly compiled code. We've got evidence from a real service it is not a good idea to reduce the default size. The service had CodeCache trashing. Performance degradation caused by CodeCache trashing is huge and really hard to detect.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From duke at openjdk.org  Thu Jun 30 21:35:36 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Thu, 30 Jun 2022 21:35:36 GMT
Subject: RFR: 8280481: Duplicated stubs to interpreter for static calls
In-Reply-To: <ONVSGWta7auQsl98toVizl8e6L9USdeZNzwdrg48gmQ=.d71dd705-43cb-43b7-a3f1-a18e40ec103f@github.com>
References: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com>
 <t1Gigc1XLRETSXriG2Bw9-zZGbaJxxIj-Hda3sRBGf8=.60774236-39cc-4f39-b757-076d33af675b@github.com>
 <B8WuOWl_39ppfyZuz8fAoCmlwSPvDzLFF1ikhF-N0S8=.fd498ddb-7854-4616-802c-a0675dbb031c@github.com>
 <ONVSGWta7auQsl98toVizl8e6L9USdeZNzwdrg48gmQ=.d71dd705-43cb-43b7-a3f1-a18e40ec103f@github.com>
Message-ID: <vPjJ-ij2UIcCOdvy3w11AdlcwDwn57plSA9yt3RTHHc=.73d285ea-72e1-4b6a-9ea8-1196a3327659@github.com>

On Fri, 17 Jun 2022 09:25:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > If we never patch the branch to the interpreter, we can optimize it at link time either to a direct branch or an adrp based far jump. I also created https://bugs.openjdk.org/browse/JDK-8286142 to reduce metadata mov instructions.
> 
> If we emit the address of the interpreter once, at the start of the stub section, we can replace the branch to the interpreter with `ldr rscratch1, adr; br rscratch1`.

@theRealAph, thank you for the idea.
I created https://bugs.openjdk.org/browse/JDK-8289057.

-------------

PR: https://git.openjdk.org/jdk/pull/8816

From jwilhelm at openjdk.org  Thu Jun 30 23:58:47 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 30 Jun 2022 23:58:47 GMT
Subject: RFR: Merge jdk19
Message-ID: <kaKg5e38rdUlc_wErqo1jlpqjTiiV933wuysiy58Rug=.ae562436-c6cf-4c43-90b9-bc082c9397a7@github.com>

Forwardport JDK 19 -> JDK 20

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and can_support_virtual_threads

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/9341/files
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9341.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9341/head:pull/9341

PR: https://git.openjdk.org/jdk/pull/9341