From wkemper at openjdk.java.net  Tue Mar  1 00:16:45 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 1 Mar 2022 00:16:45 GMT
Subject: Integrated: Remove young generation access to old generation mark
 queues earlier
In-Reply-To: <yhnw2hMYJSCtlnksdSO--UH86c5Sl78SpScXy2hXAzM=.45235624-0583-4d02-b7bb-3135f7d53db1@github.com>
References: <yhnw2hMYJSCtlnksdSO--UH86c5Sl78SpScXy2hXAzM=.45235624-0583-4d02-b7bb-3135f7d53db1@github.com>
Message-ID: <uP_Fq3DAoK0Y-4xgRnmUF7QqF7dECeZcBu4XHYu-NfU=.ed533e9e-9728-43d4-a4f8-1098abcd11a9@github.com>

On Mon, 28 Feb 2022 23:34:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Prior to this change, we removed access to the old generation mark queues if (and only if) the old generation cycle completed. However, in some cases, the old generation cycle may be interrupted _after_ it has finished marking but _before_ it has finished preparing for mixed collections. This error may cause young generation cycles to enqueue old objects into the old generation mark queues that may become invalid as mixed collections execute. With this change, we remove access to old generation mark queues as soon as old generation marking is complete.

This pull request has now been integrated.

Changeset: b54dca1e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/b54dca1e029135985509e926346b38d3ee0a0c3c
Stats:     8 lines in 2 files changed: 5 ins; 3 del; 0 mod

Remove young generation access to old generation mark queues earlier

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/120

From kvn at openjdk.java.net  Tue Mar  1 18:35:11 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Mar 2022 18:35:11 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
Message-ID: <zBV5lRyQbt80Uunvs41yvChPgs1uhWk169K76v-E2gk=.3bc68cb9-c67c-42ca-b65e-e306765bc30e@github.com>

On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Resolve merge conflict
>  - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
>  - aarch64: fix issue with short inputs divisible by wordSize
>  - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
>  - Revert micro changes, split out to #7516
>  - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce

Looks good.

@theRealAph , @a74nh  or someone familiar with aarch64 code, please review aarch64 changes.

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

Marked as reviewed by kvn (Reviewer).

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

From lucy at openjdk.java.net  Tue Mar  1 18:41:11 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 1 Mar 2022 18:41:11 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
Message-ID: <yd-oz_Rre116QuNeDA0ohVAfgJ3Yb2t8kLF9eGI8VvI=.05f3e923-b4e7-41b9-bad5-bcd4a4249791@github.com>

On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Resolve merge conflict
>  - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
>  - aarch64: fix issue with short inputs divisible by wordSize
>  - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
>  - Revert micro changes, split out to #7516
>  - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce

@cl4ea How do you plan to proceed with the PPC (PR#7430) and s390 (PR#7604) intrinsic implementations? We (Martin and myself) would not object if you would just integrate the changes into this PR.

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

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

From redestad at openjdk.java.net  Tue Mar  1 19:15:04 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 1 Mar 2022 19:15:04 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <zBV5lRyQbt80Uunvs41yvChPgs1uhWk169K76v-E2gk=.3bc68cb9-c67c-42ca-b65e-e306765bc30e@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
 <zBV5lRyQbt80Uunvs41yvChPgs1uhWk169K76v-E2gk=.3bc68cb9-c67c-42ca-b65e-e306765bc30e@github.com>
Message-ID: <XIlncwE7gT07-5X0bGZ-xooeH9tFqqe-vzC780DxLgA=.85467437-e455-4d72-a57a-4662bbf1b13b@github.com>

On Tue, 1 Mar 2022 18:32:00 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes.

Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc changes, but since no precise calculation is implemented for aarch64 then there's no speed-up on micros such as `encodeLatin1LongEnd` for now. I would like to defer such optimization work to a follow-up.

@RealLucy yes, I'd like to integrate your changes into this patch and drop the `HasNegativesNode` et.c. You mentioned in e-mail some issue with the code generation on s390 - has that been resolved or identified?

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

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

From lucy at openjdk.java.net  Tue Mar  1 22:05:04 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 1 Mar 2022 22:05:04 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <XIlncwE7gT07-5X0bGZ-xooeH9tFqqe-vzC780DxLgA=.85467437-e455-4d72-a57a-4662bbf1b13b@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
 <zBV5lRyQbt80Uunvs41yvChPgs1uhWk169K76v-E2gk=.3bc68cb9-c67c-42ca-b65e-e306765bc30e@github.com>
 <XIlncwE7gT07-5X0bGZ-xooeH9tFqqe-vzC780DxLgA=.85467437-e455-4d72-a57a-4662bbf1b13b@github.com>
Message-ID: <gHPcwjQoOP6zQnDsBrxP7K_hZp7t6e5xZFJ38Na_IvQ=.3999c1c7-d137-47b4-9c4e-8a2fd587a110@github.com>

On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @theRealAph , @a74nh  or someone familiar with aarch64 code, please review aarch64 changes.
>
>> @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes.
> 
> Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc changes, but since no precise calculation is implemented for aarch64 then there's no speed-up on micros such as `encodeLatin1LongEnd` for now. I would like to defer such optimization work to a follow-up.
> 
> @RealLucy yes, I'd like to integrate your changes into this patch and drop the `HasNegativesNode` et.c. You mentioned in e-mail some issue with the code generation on s390 - has that been resolved or identified?

@cl4es This issue in code generation (checking the intrinsic return value for < 0 where it only can be >= 0) is not specific to s390. It is as well visible on x86_64 and on ppc. It happens with the SPECjvm2008 sub-benchmark compiler.sunflow. What's specific to s390 is the fact that this obviously erroneous check causes the benchmark to fail. x86_64 and ppc seem to be immune. Where the immunity comes from is not yet understood.

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

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

From redestad at openjdk.java.net  Wed Mar  2 14:12:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 2 Mar 2022 14:12:33 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
Message-ID: <wUwL-YrWiI66ZXf5OqrywPz7P_nTd8CQB7ji8g6o920=.1168e866-c72b-4cf2-9954-1cfab23eef72@github.com>

On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Resolve merge conflict
>  - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
>  - aarch64: fix issue with short inputs divisible by wordSize
>  - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
>  - Revert micro changes, split out to #7516
>  - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
>  - Merge branch 'master' into count_positives
>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>  - Simplify changes to encodeUTF8
>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce

> 

Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless.

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

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

From redestad at openjdk.java.net  Wed Mar  2 14:12:31 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 2 Mar 2022 14:12:31 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v7]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <UArDrMciJzrFQFKisgZvKmcDnKQbOVr4gbFfbVdmGUA=.09b6dd71-e74a-4eed-bcc1-246e57ca0f5c@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Narrow the bottom_type of CountPositivesNode (always results in a positive int value)
 - Merge master
 - Resolve merge conflict
 - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
 - aarch64: fix issue with short inputs divisible by wordSize
 - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
 - Revert micro changes, split out to #7516
 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
 - Merge branch 'master' into count_positives
 - Restore partial vector checks in AVX2 and SSE intrinsic variants
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/d4d12ad1...7789349a

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

Changes: https://git.openjdk.java.net/jdk/pull/7231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=06
  Stats: 527 lines in 29 files changed: 309 ins; 49 del; 169 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From aph at openjdk.java.net  Wed Mar  2 14:28:06 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 2 Mar 2022 14:28:06 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <XIlncwE7gT07-5X0bGZ-xooeH9tFqqe-vzC780DxLgA=.85467437-e455-4d72-a57a-4662bbf1b13b@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
 <zBV5lRyQbt80Uunvs41yvChPgs1uhWk169K76v-E2gk=.3bc68cb9-c67c-42ca-b65e-e306765bc30e@github.com>
 <XIlncwE7gT07-5X0bGZ-xooeH9tFqqe-vzC780DxLgA=.85467437-e455-4d72-a57a-4662bbf1b13b@github.com>
Message-ID: <KsuuWqYq-jWNQ-ltng1KVItHoUxpSPVhwej4aWUqWzg=.2628c539-749c-45ef-8b97-b70ff2eb9ec6@github.com>

On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes.
> 
> Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc 

Sure. And we don't have to check which of the 8 bytes in a word has its top bit set, so we don't have to do any more work, just return the count when we stopped searching. So there's no possible performance regression on AArch64 as far as I can see.

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

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

From wkemper at openjdk.java.net  Wed Mar  2 17:04:59 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 2 Mar 2022 17:04:59 GMT
Subject: RFR: Reset update watermark for cycles degenerated during evacuation
Message-ID: <GFmEV8lzkAZV_u6LJ1f2t1DdDhNo3G48MQA9FxkwSkE=.938f985f-bbc0-4f8a-981c-5d8ea2b36d09@github.com>

When an out of memory error occurs during concurrent evacuation the load reference barrier (LRB) stops trying to evacuate objects (this appears to be by design). As the collector transitions to a degenerated cycle, mutators may load references to objects in the collection set. If one of these references is written into a region that was `empty committed` after final mark, the region will have its top at mark start (TAMS) and update watermark (UWM) equal to the bottom of the region. Such regions are effectively skipped during the update reference phase. The degenerated cycle completes with live references to reclaimed memory in the heap, resulting in crashes or corruption.

Rather than re-engineer the oom-during-evac protocol, upon entering a degenerated evacuation phase we again make thread local allocation buffers (TLABs) parsable and reset the UWM for active regions. Now, if the degenerated evacuation phase succeeds, the from-space pointers will be fixed in the update reference phase.

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

Commit messages:
 - Only retire tlabs if tlabs are in use
 - Reset update watermark (and make TLABs parsable) for cycles degenerated during evacuation

Changes: https://git.openjdk.java.net/shenandoah/pull/121/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=121&range=00
  Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/121.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/121/head:pull/121

PR: https://git.openjdk.java.net/shenandoah/pull/121

From kdnilsen at openjdk.java.net  Wed Mar  2 17:58:38 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 2 Mar 2022 17:58:38 GMT
Subject: RFR: Reset update watermark for cycles degenerated during
 evacuation
In-Reply-To: <GFmEV8lzkAZV_u6LJ1f2t1DdDhNo3G48MQA9FxkwSkE=.938f985f-bbc0-4f8a-981c-5d8ea2b36d09@github.com>
References: <GFmEV8lzkAZV_u6LJ1f2t1DdDhNo3G48MQA9FxkwSkE=.938f985f-bbc0-4f8a-981c-5d8ea2b36d09@github.com>
Message-ID: <yiNg8F6k_TLIVEIU-cN0x-jXu6sjTyMHEd44Gd7ZrA4=.633d8cc4-451e-4ccb-bc98-98fa3d08b7e7@github.com>

On Wed, 2 Mar 2022 16:58:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When an out of memory error occurs during concurrent evacuation the load reference barrier (LRB) stops trying to evacuate objects (this appears to be by design). As the collector transitions to a degenerated cycle, mutators may load references to objects in the collection set. If one of these references is written into a region that was `empty committed` after final mark, the region will have its top at mark start (TAMS) and update watermark (UWM) equal to the bottom of the region. Such regions are effectively skipped during the update reference phase. The degenerated cycle completes with live references to reclaimed memory in the heap, resulting in crashes or corruption.
> 
> Rather than re-engineer the oom-during-evac protocol, upon entering a degenerated evacuation phase we again make thread local allocation buffers (TLABs) parsable and reset the UWM for active regions. Now, if the degenerated evacuation phase succeeds, the from-space pointers will be fixed in the update reference phase.

Thanks for this fix.

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

Marked as reviewed by kdnilsen (Committer).

PR: https://git.openjdk.java.net/shenandoah/pull/121

From wkemper at openjdk.java.net  Wed Mar  2 18:00:27 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 2 Mar 2022 18:00:27 GMT
Subject: git: openjdk/shenandoah: master: Reset update watermark for cycles
 degenerated during evacuation
Message-ID: <3e2b3018-dd07-49d7-ab0b-1a7e5288a6bb@openjdk.org>

Changeset: 98b21327
Author:    William Kemper <wkemper at openjdk.org>
Date:      2022-03-02 17:59:55 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/98b21327d650326486daf5db2ffdf8fd8dde59b8

Reset update watermark for cycles degenerated during evacuation

Reviewed-by: kdnilsen

! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp


From wkemper at openjdk.java.net  Wed Mar  2 18:03:50 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 2 Mar 2022 18:03:50 GMT
Subject: Integrated: Reset update watermark for cycles degenerated during
 evacuation
In-Reply-To: <GFmEV8lzkAZV_u6LJ1f2t1DdDhNo3G48MQA9FxkwSkE=.938f985f-bbc0-4f8a-981c-5d8ea2b36d09@github.com>
References: <GFmEV8lzkAZV_u6LJ1f2t1DdDhNo3G48MQA9FxkwSkE=.938f985f-bbc0-4f8a-981c-5d8ea2b36d09@github.com>
Message-ID: <hAPDxVTxRhLL6djORtZj2V8n8b9TgQnjUxHhN5Ay2VQ=.18dd10ce-ae40-4ed1-a485-c437b292f7e5@github.com>

On Wed, 2 Mar 2022 16:58:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When an out of memory error occurs during concurrent evacuation the load reference barrier (LRB) stops trying to evacuate objects (this appears to be by design). As the collector transitions to a degenerated cycle, mutators may load references to objects in the collection set. If one of these references is written into a region that was `empty committed` after final mark, the region will have its top at mark start (TAMS) and update watermark (UWM) equal to the bottom of the region. Such regions are effectively skipped during the update reference phase. The degenerated cycle completes with live references to reclaimed memory in the heap, resulting in crashes or corruption.
> 
> Rather than re-engineer the oom-during-evac protocol, upon entering a degenerated evacuation phase we again make thread local allocation buffers (TLABs) parsable and reset the UWM for active regions. Now, if the degenerated evacuation phase succeeds, the from-space pointers will be fixed in the update reference phase.

This pull request has now been integrated.

Changeset: 98b21327
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/98b21327d650326486daf5db2ffdf8fd8dde59b8
Stats:     21 lines in 1 file changed: 21 ins; 0 del; 0 mod

Reset update watermark for cycles degenerated during evacuation

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/121

From lucy at openjdk.java.net  Wed Mar  2 22:44:24 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 2 Mar 2022 22:44:24 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <wUwL-YrWiI66ZXf5OqrywPz7P_nTd8CQB7ji8g6o920=.1168e866-c72b-4cf2-9954-1cfab23eef72@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
 <wUwL-YrWiI66ZXf5OqrywPz7P_nTd8CQB7ji8g6o920=.1168e866-c72b-4cf2-9954-1cfab23eef72@github.com>
Message-ID: <mB0mnxZvFb031xFH4NS0Ex8gQgHWY7oqC8yQ7_gRPgg=.90ee7bb6-6ec0-4418-9a8f-a865c982ad64@github.com>

On Wed, 2 Mar 2022 14:06:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Resolve merge conflict
>>  - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
>>  - aarch64: fix issue with short inputs divisible by wordSize
>>  - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
>>  - Revert micro changes, split out to #7516
>>  - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
>>  - Merge branch 'master' into count_positives
>>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>>  - Simplify changes to encodeUTF8
>>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce
>
>> 
> 
> Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless.

@cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives.

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

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

From redestad at openjdk.java.net  Thu Mar  3 12:04:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 3 Mar 2022 12:04:47 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/3207c098..85be36ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=07-08

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

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

From redestad at openjdk.java.net  Thu Mar  3 12:14:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 3 Mar 2022 12:14:10 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v6]
In-Reply-To: <wUwL-YrWiI66ZXf5OqrywPz7P_nTd8CQB7ji8g6o920=.1168e866-c72b-4cf2-9954-1cfab23eef72@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <GGlhZ0PA4ylRTq3mOm5QaAKjc38LKaVNfRZd-m9LqwY=.c36c7db0-c00c-4e1b-bf6d-8f48edd8b6b5@github.com>
 <wUwL-YrWiI66ZXf5OqrywPz7P_nTd8CQB7ji8g6o920=.1168e866-c72b-4cf2-9954-1cfab23eef72@github.com>
Message-ID: <Xv4gIhDdusggBCcmG7AYN_0juAhmjccRijGZwMDHfXU=.26818333-7be9-4886-b760-c8c09869a729@github.com>

On Wed, 2 Mar 2022 14:06:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Resolve merge conflict
>>  - Fix TestCountPositives to correctly allow 0 return when expected != len (for now)
>>  - aarch64: fix issue with short inputs divisible by wordSize
>>  - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step.
>>  - Revert micro changes, split out to #7516
>>  - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives
>>  - Merge branch 'master' into count_positives
>>  - Restore partial vector checks in AVX2 and SSE intrinsic variants
>>  - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral
>>  - Simplify changes to encodeUTF8
>>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce
>
>> 
> 
> Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless.

> @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives.

I was going back and forth on this since the annotation might be used as a useful marker by other JVM implementors, so wasn't sure if removing the annotation would need to go through a deprecation cycle. I've removed it now; let's see if there are any objections to that.

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

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

From aph at openjdk.java.net  Thu Mar  3 12:34:07 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 3 Mar 2022 12:34:07 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
Message-ID: <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>

On Thu, 3 Mar 2022 12:04:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes)

>     * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?

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

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

From redestad at openjdk.java.net  Thu Mar  3 12:49:06 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 3 Mar 2022 12:49:06 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
Message-ID: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>

On Thu, 3 Mar 2022 12:30:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > ```
> > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
> > ```
> 
> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?

Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. 

I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back.

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

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

From lucy at openjdk.java.net  Thu Mar  3 13:25:03 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 3 Mar 2022 13:25:03 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
 <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
Message-ID: <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>

On Thu, 3 Mar 2022 12:45:51 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>>     * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>> 
>> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?
>
>> > ```
>> > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>> > ```
>> 
>> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already?
> 
> Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. 
> 
> I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back.

> > @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives.
> 
> I was going back and forth ...

Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying...

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

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

From redestad at openjdk.java.net  Thu Mar  3 13:35:02 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 3 Mar 2022 13:35:02 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
 <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
 <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>
Message-ID: <MujW-BZWklHyPGBzMCcRem7BSlTsqsdJm6L2EKu0Nbw=.e092ba7e-d3da-4ba1-8972-88412792da34@github.com>

On Thu, 3 Mar 2022 13:21:36 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying...

Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..). I also seem to have built-and-tested locally without that patch properly applied. Sorry for the noise, should be fixed now.

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

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

From aph at openjdk.java.net  Thu Mar  3 14:40:58 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 3 Mar 2022 14:40:58 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <MujW-BZWklHyPGBzMCcRem7BSlTsqsdJm6L2EKu0Nbw=.e092ba7e-d3da-4ba1-8972-88412792da34@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
 <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
 <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>
 <MujW-BZWklHyPGBzMCcRem7BSlTsqsdJm6L2EKu0Nbw=.e092ba7e-d3da-4ba1-8972-88412792da34@github.com>
Message-ID: <nKX_k3sDT8365mNLO0VpWJ9q6ZRBB50FBbD4l6miV8Q=.a6073ec2-cfe5-426e-9baf-7079cd5da4f9@github.com>

On Thu, 3 Mar 2022 13:31:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying...
> 
> Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..).

I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot.

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

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

From lucy at openjdk.java.net  Thu Mar  3 14:47:02 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 3 Mar 2022 14:47:02 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <nKX_k3sDT8365mNLO0VpWJ9q6ZRBB50FBbD4l6miV8Q=.a6073ec2-cfe5-426e-9baf-7079cd5da4f9@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
 <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
 <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>
 <MujW-BZWklHyPGBzMCcRem7BSlTsqsdJm6L2EKu0Nbw=.e092ba7e-d3da-4ba1-8972-88412792da34@github.com>
 <nKX_k3sDT8365mNLO0VpWJ9q6ZRBB50FBbD4l6miV8Q=.a6073ec2-cfe5-426e-9baf-7079cd5da4f9@github.com>
Message-ID: <qz_xTsD9VbzHXB1ChSCg_8pOiRCHL9kFghjnIsPGyak=.2d83171f-ea12-48ea-85dd-3f8394ab7cdc@github.com>

On Thu, 3 Mar 2022 14:37:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying...
> > 
> > 
> > Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..).
> 
> I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot.

Yes, sorry for the imprecise wording: the declaration must be there. Use of the intrinsic is then controlled via has_match_rule(opcode) and match_rule_supported(opcode).

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

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

From redestad at openjdk.java.net  Thu Mar  3 14:51:01 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 3 Mar 2022 14:51:01 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v9]
In-Reply-To: <qz_xTsD9VbzHXB1ChSCg_8pOiRCHL9kFghjnIsPGyak=.2d83171f-ea12-48ea-85dd-3f8394ab7cdc@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <jW436-j5p7luPTw_EuNDdWUZ7Zpv-EQ_vlUsKmmob0w=.4a5815fa-9ea7-4093-8b85-3167e3720b70@github.com>
 <mcr3T7CMzA3-xvnC8HLH2IoFRSr99VVxUjVgDFHps7Q=.3c7e91a5-a51c-476e-a5d2-bd4afac2f029@github.com>
 <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com>
 <KzNCVbA1m-52c1GfXXmw_PQ7jyXqMqPKf-hkb1Eyk34=.dd7451bf-2fbb-49a2-8e2b-aab3bc2fb01e@github.com>
 <MujW-BZWklHyPGBzMCcRem7BSlTsqsdJm6L2EKu0Nbw=.e092ba7e-d3da-4ba1-8972-88412792da34@github.com>
 <nKX_k3sDT8365mNLO0VpWJ9q6ZRBB50FBbD4l6miV8Q=.a6073ec2-cfe5-426e-9baf-7079cd5da4f9@github.com>
 <qz_xTsD9VbzHXB1ChSCg_8pOiRCHL9kFghjnIsPGyak=.2d83171f-ea12-48ea-85dd-3f8394ab7cdc@github.com>
Message-ID: <et3uoucEpZCGZd3DoN-9CMVKurD5fTynKIHTlIIDBWM=.d57782f0-fe8f-499a-b32a-713b915c28eb@github.com>

On Thu, 3 Mar 2022 14:43:52 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot.

Yeah, I got confused. To me it looks like a declaration of intent, and thought the only strict requirement was that HotSpot can't define an intrinsic if there's no annotation. It also seems odd to hardwire it to what HotSpot does - wasn't the purpose of renaming from `@HotSpotIntrinsicCandidate` to decouple things a bit better?

Either way.. I'm re-running tests and benchmarks and seeing if I can improve the aarch64 impl to return a decent approximation rather than always-0 when there are negative bytes.

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

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

From wkemper at openjdk.java.net  Fri Mar  4 22:20:00 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 4 Mar 2022 22:20:00 GMT
Subject: RFR: Age objects before installing forwarding pointer to them
Message-ID: <P5I6JFRomhXGYqoL4bitBFvn3n-LwyxKT5eZ_cWlIPc=.9fed25f0-5478-488a-b92f-fa3a9d4339c8@github.com>

We cannot safely manipulate the mark word concurrently with mutators. This _should_ fix a crash issue reported on PPC 64.

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

Commit messages:
 - Age objects before installing forwarding pointer to them

Changes: https://git.openjdk.java.net/shenandoah/pull/122/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=122&range=00
  Stats: 14 lines in 1 file changed: 4 ins; 8 del; 2 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/122/head:pull/122

PR: https://git.openjdk.java.net/shenandoah/pull/122

From kdnilsen at openjdk.java.net  Fri Mar  4 22:26:39 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 4 Mar 2022 22:26:39 GMT
Subject: RFR: Age objects before installing forwarding pointer to them
In-Reply-To: <P5I6JFRomhXGYqoL4bitBFvn3n-LwyxKT5eZ_cWlIPc=.9fed25f0-5478-488a-b92f-fa3a9d4339c8@github.com>
References: <P5I6JFRomhXGYqoL4bitBFvn3n-LwyxKT5eZ_cWlIPc=.9fed25f0-5478-488a-b92f-fa3a9d4339c8@github.com>
Message-ID: <uMnuYmTRXLg9Zkm2pu5zRIHbF2tYlgEuGrfypxRr-yQ=.7adbaaf9-f532-446f-92ee-bb2b037fadfa@github.com>

On Fri, 4 Mar 2022 22:15:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We cannot safely manipulate the mark word concurrently with mutators. This _should_ fix a crash issue reported on PPC 64.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/122

From wkemper at openjdk.java.net  Fri Mar  4 22:36:41 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 4 Mar 2022 22:36:41 GMT
Subject: Integrated: Age objects before installing forwarding pointer to them
In-Reply-To: <P5I6JFRomhXGYqoL4bitBFvn3n-LwyxKT5eZ_cWlIPc=.9fed25f0-5478-488a-b92f-fa3a9d4339c8@github.com>
References: <P5I6JFRomhXGYqoL4bitBFvn3n-LwyxKT5eZ_cWlIPc=.9fed25f0-5478-488a-b92f-fa3a9d4339c8@github.com>
Message-ID: <Guga1QSDk7hNYw3oAKyzdc3P9us3z4O1U9-FK76YZAk=.ece04373-a6df-4120-8122-59c2be05b722@github.com>

On Fri, 4 Mar 2022 22:15:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We cannot safely manipulate the mark word concurrently with mutators. This _should_ fix a crash issue reported on PPC 64.

This pull request has now been integrated.

Changeset: a2b5be26
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/a2b5be26bfc85b4c445f82697856bef8bd6175f6
Stats:     14 lines in 1 file changed: 4 ins; 8 del; 2 mod

Age objects before installing forwarding pointer to them

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/122

From duke at openjdk.java.net  Mon Mar  7 11:36:21 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 11:36:21 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
Message-ID: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>

The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

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

Commit messages:
 - Fix include for threadWXSetters.inline.hpp
 - Remove thread parameter from ThreadWXEnable
 - Remove thread parameter from os methods
 - Remove wx_init and current thread assert in safefetch
 - Use os::current_thread_change_wx instead of thread methods

Changes: https://git.openjdk.java.net/jdk/pull/7727/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7727&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282475
  Stats: 150 lines in 31 files changed: 26 ins; 47 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7727/head:pull/7727

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

From dholmes at openjdk.java.net  Mon Mar  7 12:19:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 12:19:06 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Hi Johannes,

The general idea seems good (pity it touches so many files, but then I've never liked any of this WX support precisely because it is so invasive of shared code). I agree that safeFetch should not have become dependent on Thread::current existing, but I have to wonder whether we can just skip the WX code if there is no current thread? If the thread is not attached to the VM then what does it even mean to manipulate the WX state of an unknown thread?

That aside, with this change I think we can move the conditional WX code out of the shared os.hpp and bury it down in os_bsd_aarch64.hpp where it actually belongs. 

I'd even like to see threadWXSetters.inline.hpp moved to being in src/os_cpu/bsd_aarch64/ if feasible - I'm not sure what include would be needed for the callsites to function - os.hpp I presume?

Thanks,
David

src/hotspot/share/runtime/threadWXSetters.inline.hpp line 33:

> 31: #if defined(__APPLE__) && defined(AARCH64)
> 32: 
> 33: #include "runtime/thread.inline.hpp" // dependencies require this include

I can't see how this include is needed now.

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

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

From duke at openjdk.java.net  Mon Mar  7 12:29:03 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 12:29:03 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>
Message-ID: <YY43SDBzaTUKr6e8fcskETGhXRBleQwt8nqj8KtHNLQ=.17496ed2-c14b-477b-8529-3f9f4f5ba7b1@github.com>

On Mon, 7 Mar 2022 12:07:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> src/hotspot/share/runtime/threadWXSetters.inline.hpp line 33:
> 
>> 31: #if defined(__APPLE__) && defined(AARCH64)
>> 32: 
>> 33: #include "runtime/thread.inline.hpp" // dependencies require this include
> 
> I can't see how this include is needed now.

I tried to replace it with os.hpp (and os.inline.hpp) but it caused a linker error.

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

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

From duke at openjdk.java.net  Mon Mar  7 12:34:04 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 12:34:04 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>
Message-ID: <dz9xwiPs13b8Z2guFWDIhC6BW_A8mZuBq5gjJLVh1lQ=.7aaa753c-2d14-4a8a-b065-f414e315d224@github.com>

On Mon, 7 Mar 2022 12:16:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I agree that safeFetch should not have become dependent on Thread::current existing, but I have to wonder whether we can just skip the WX code if there is no current thread? If the thread is not attached to the VM then what does it even mean to manipulate the WX state of an unknown thread?

The OS thread is always known. The WXMode is unrelated to Thread object. The WXMode is set for an OS thread to allow pages to be either writable or executable (needed for code generation).

> That aside, with this change I think we can move the conditional WX code out of the shared os.hpp and bury it down in os_bsd_aarch64.hpp where it actually belongs.

May I ask how that would affect the code that uses the methods (includes, ...)?

> I'd even like to see threadWXSetters.inline.hpp moved to being in src/os_cpu/bsd_aarch64/ if feasible - I'm not sure what include would be needed for the callsites to function - os.hpp I presume?

I don't know whether this is enough.

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

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

From stuefe at openjdk.java.net  Mon Mar  7 14:27:06 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 7 Mar 2022 14:27:06 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <yn_D3H7p4Brx6rPTCwLvbPOGb93D4jIYo8aL3JoyTwk=.7bef2aa4-9df3-498b-a784-2cf871193cc0@github.com>

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Hi David,

> The general idea seems good (pity it touches so many files, but then I've never liked any of this WX support precisely because it is so invasive of shared code). I agree that safeFetch should not have become dependent on Thread::current existing, but I have to wonder whether we can just skip the WX code if there is no current thread? If the thread is not attached to the VM then what does it even mean to manipulate the WX state of an unknown thread?

We need to change the wx state of the current pthread in order to be able to execute stub routines. Otherwise, we would crash right away when trying to execute the SafeFetch stub.

And that is a valid requirement. Let's say we crash in a native thread, unrelated to and completely oblivious of the JVM it shares the process with. We'd still want to see e.g. native crash information, stack frames, maybe register region information etc - all that stuff that may require SafeFetch. In fact, this patch is related to Johannes other PR where he modified stack frame walking to check that the registers point into valid memory. 

> 
> That aside, with this change I think we can move the conditional WX code out of the shared os.hpp and bury it down in os_bsd_aarch64.hpp where it actually belongs.

Oh yes!

> 
> I'd even like to see threadWXSetters.inline.hpp moved to being in src/os_cpu/bsd_aarch64/ if feasible - I'm not sure what include would be needed for the callsites to function - os.hpp I presume?

I agree, all that wx stuff should be limited to os/bsd or os/bsd_aarch. 

We could have generic wrappers like:


class os {
...
// Platform does whatever needed to prepare for execution of generated code inside the current thread
os::pre_current_thread_jit_call() NOT_MACOS_AARCH64({})
// Platform does whatever needed to clean up after executing generated code inside the current thread
os::post_current_thread_jit_call() NOT_MACOS_AARCH64({})


(Macro does not yet exist, but MACOS_AARCH64_ONLY does)

--

Side note, I think we have reached a point where it would be cleaner to split xxxBSD and MacOS sources. E.g. this wx stuff should be limited to MacOS too, and we have more and more `__APPLE_` only sections.

Cheers, Thomas

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

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

From stuefe at openjdk.java.net  Mon Mar  7 14:52:26 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 7 Mar 2022 14:52:26 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <u-SNQcPDNHXtOPOgkvw_uQCV1LngjRkt6r8tWOf6_pU=.3f39fdfa-5301-4600-ad2f-f28d66b908b9@github.com>

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Hi Johannes, just some drive-by comments, not a full review. Also please see my comment toward David, proposing a more generic interface in os instead.

Cheers, Thomas

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 537:

> 535: #endif
> 536: 
> 537: static THREAD_LOCAL WXMode _wx_state = WXUnknown;

All this wx coding inside bsd sources should be guarded with `__APPLE__` out of politeness toward the BSDs.

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 552:

> 550:     _wx_state = new_state;
> 551:     pthread_jit_write_protect_np(_wx_state == WXExec);
> 552:   }

I would simplify this:


if (_wx_state == unknown) {
  _wx_state = write; // No way to know but we assume the original state is "writable, not executable"
}
WXMode old = _wx_state;
_wx_state = new_state;
pthread_jit_write_protect_np(_wx_state == WXExec);
}


that is simpler and avoids calling pthread_jit_write_protect_np twice for the "unknown->exec" transition.

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 558:

> 556: void os::current_thread_reset_wx() {
> 557:   current_thread_change_wx(WXWrite);
> 558: }

I find the naming a  bit misleading. You use this as initialization, so I would call it "init" something.

Then, I'm not sure it is even needed. I know you just transformed it from the original `init_wx()`, so the question is directed more at the original authors (@AntonKozlov?).

AFAIU we use this to initialize wxstate for newly attached threads to "dont execute". But should this not already be the case? And if its not - e.g. because that thread had been calling into another library that also does call generated code - is it not impolite to switch the state to "executable false"? I know this is highly unlikely, I just try to understand.

src/hotspot/share/runtime/os.hpp line 943:

> 941:   static WXMode current_thread_change_wx(WXMode new_state);
> 942: 
> 943:   static void current_thread_reset_wx();

Please add comments what this is supposed to do

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

Changes requested by stuefe (Reviewer).

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

From duke at openjdk.java.net  Mon Mar  7 15:11:09 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 15:11:09 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <u-SNQcPDNHXtOPOgkvw_uQCV1LngjRkt6r8tWOf6_pU=.3f39fdfa-5301-4600-ad2f-f28d66b908b9@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <u-SNQcPDNHXtOPOgkvw_uQCV1LngjRkt6r8tWOf6_pU=.3f39fdfa-5301-4600-ad2f-f28d66b908b9@github.com>
Message-ID: <kLDwzP7kBEuEXO5Lq5-t8nxmxQvCe_1Vif8-fOdZ-Wc=.81a96f6b-e264-4d02-95d7-beabe708d222@github.com>

On Mon, 7 Mar 2022 14:42:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I find the naming a bit misleading. You use this as initialization, so I would call it "init" something.

You're correct.

> AFAIU we use this to initialize wxstate for newly attached threads to "dont execute". But should this not already be the case? 

No, it does not seem to be the case: https://github.com/dotnet/runtime/issues/41991  (and the man page does not give a default value either)

> And if its not - e.g. because that thread had been calling into another library that also does call generated code - is it not impolite to switch the state to "executable false"? I know this is highly unlikely, I just try to understand.

This might be an issue when calling another library with a JIT. But this seems to be highly unlikely. Especially as this would have already been an issue.

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

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

From duke at openjdk.java.net  Mon Mar  7 15:17:07 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 15:17:07 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <JnEfeSXG45MFGGJ50jiRoXEr-1WUZKJgrp_FVuUlwDU=.2f8cc4ea-856a-4d36-89f7-dd32cec3076e@github.com>

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Regarding the names of the new methods: Most of the usages for ThreadWXEnable use it to set the WXMode to WXWrite. The suggested names are therefore a bit misleading (when used in this context).

One could add another two methods:


class os {
...
// Platform does whatever needed to prepare for execution of generated code inside the current thread
os::pre_current_thread_jit_code_gen() NOT_MACOS_AARCH64({})
// Platform does whatever needed to clean up after executing generated code inside the current thread
os::post_current_thread_jit_code_gen() NOT_MACOS_AARCH64({})


But one would still have the problem of nesting (e.g. when code generating code calls code generating code).

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

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

From duke at openjdk.java.net  Mon Mar  7 18:31:02 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 18:31:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <YY43SDBzaTUKr6e8fcskETGhXRBleQwt8nqj8KtHNLQ=.17496ed2-c14b-477b-8529-3f9f4f5ba7b1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <LCbYWZF2JdYSvXf3haUf1MGgxy5Sp1RB8A8IXKUs5Lg=.136db112-2950-449a-82b6-fbec523ef6d6@github.com>
 <YY43SDBzaTUKr6e8fcskETGhXRBleQwt8nqj8KtHNLQ=.17496ed2-c14b-477b-8529-3f9f4f5ba7b1@github.com>
Message-ID: <hIqc8ClWZSsuNKcf6ZhnBm_-mHviMURc0RimaFa0aSI=.441c0f16-734f-4d7f-bbe1-da13aacbdbeb@github.com>

On Mon, 7 Mar 2022 12:26:00 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> src/hotspot/share/runtime/threadWXSetters.inline.hpp line 33:
>> 
>>> 31: #if defined(__APPLE__) && defined(AARCH64)
>>> 32: 
>>> 33: #include "runtime/thread.inline.hpp" // dependencies require this include
>> 
>> I can't see how this include is needed now.
>
> I tried to replace it with os.hpp (and os.inline.hpp) but it caused a linker error.

I was wrong, I removed it.

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

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

From duke at openjdk.java.net  Mon Mar  7 18:55:33 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 18:55:33 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v2]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <kkejVmZjuyBOU5CSBBaMEjRdbN98AQsizuXatpfdyYE=.f1d87f89-3388-476e-8048-91d102bf5d1d@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7727/files
  - new: https://git.openjdk.java.net/jdk/pull/7727/files/3890c1e0..886a9354

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

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

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

From dholmes at openjdk.java.net  Mon Mar  7 21:36:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Mar 2022 21:36:08 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <yn_D3H7p4Brx6rPTCwLvbPOGb93D4jIYo8aL3JoyTwk=.7bef2aa4-9df3-498b-a784-2cf871193cc0@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <yn_D3H7p4Brx6rPTCwLvbPOGb93D4jIYo8aL3JoyTwk=.7bef2aa4-9df3-498b-a784-2cf871193cc0@github.com>
Message-ID: <xTUj-uO-8A0euzjPULIMThcIFIgyvH-Cd9ys5OUm_xU=.203c555d-f08e-403e-9dc2-ffa182caef9c@github.com>

On Mon, 7 Mar 2022 14:24:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> We need to change the wx state of the current pthread in order to be able to execute stub routines. Otherwise, we would crash right away when trying to execute the SafeFetch stub.

Oh I see - that is unfortunate. I don't like messing with other people's threads.

> May I ask how that would affect the code that uses the methods (includes, ...)?

@parttimenerd there would be no change - they continue to include os.hpp, which will include the os/cpu specific header files.

> We could have generic wrappers like: ...

@tstuefe  I think this is going a little too far in this fix. I'm looking for simplicity. All the WX related code should be buried in the os/cpu file for BSD/Aarch64 and the callsites all using MACOS_AARCH64_ONLY.

Splitting BSD from macOS would also be a future RFE.

Thanks.

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

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

From duke at openjdk.java.net  Mon Mar  7 21:41:01 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 7 Mar 2022 21:41:01 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v2]
In-Reply-To: <kkejVmZjuyBOU5CSBBaMEjRdbN98AQsizuXatpfdyYE=.f1d87f89-3388-476e-8048-91d102bf5d1d@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <kkejVmZjuyBOU5CSBBaMEjRdbN98AQsizuXatpfdyYE=.f1d87f89-3388-476e-8048-91d102bf5d1d@github.com>
Message-ID: <ZzX5bMNxYbQabewxS92INMGV9AZYxF-DfElT_GVYv5I=.55a4fad7-7f8c-423a-9ae6-09c4b165ac98@github.com>

On Mon, 7 Mar 2022 18:55:33 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes

Thanks.

> All the WX related code should be buried in the os/cpu file for BSD/Aarch64 and the callsites all using MACOS_AARCH64_ONLY.

I'm currently finishing a fix that exactly does that :)

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

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

From redestad at openjdk.java.net  Mon Mar  7 23:08:49 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 7 Mar 2022 23:08:49 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v10]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <nXP-G1dGBUnRZI02XnDJuRPdL08lM1BYHk6aGbso7Dk=.575ef621-a017-43d1-bec2-03f1a08c27c7@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Better implementation for aarch64 returning roughly the count of positive bytes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/85be36ae..81ef04ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=08-09

  Stats: 34 lines in 3 files changed: 13 ins; 3 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From redestad at openjdk.java.net  Mon Mar  7 23:13:36 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 7 Mar 2022 23:13:36 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v11]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - use 32-bit mask to calculate correct remainder value
 - ary1 not required to have USE_KILL effect

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/81ef04ec..934b5b8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=09-10

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

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

From duke at openjdk.java.net  Tue Mar  8 00:25:51 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 00:25:51 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v3]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Move WX functionality into os specific files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7727/files
  - new: https://git.openjdk.java.net/jdk/pull/7727/files/886a9354..a7c38e52

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

  Stats: 163 lines in 30 files changed: 30 ins; 72 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7727/head:pull/7727

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

From dholmes at openjdk.java.net  Tue Mar  8 04:08:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 04:08:08 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v3]
In-Reply-To: <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>
Message-ID: <3-7lQJObHUh4005vGNqLqMg8SNxYcqXJPllqD3bGXjg=.6372dde6-2867-4045-ae02-cc952ebada50@github.com>

On Tue, 8 Mar 2022 00:25:51 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move WX functionality into os specific files

This is looking good. A few additional comments below.

Thanks,
David

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 538:

> 536: 
> 537: #ifdef __APPLE__
> 538: static THREAD_LOCAL os::WXMode _wx_state = os::WXUnknown;

Please add a blank line between the THREAD_LOCAL and the next method. Or even move this THREAD_LOCAL to just before `os::current_thread_change_wx`.

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 547:

> 545:   if (_wx_state == WXUnknown) {
> 546:     _wx_state = os::WXWrite; // No way to know but we assume the original state is "writable, not executable"
> 547:   }

Given this can't you just initialize to WXWrite and do away with WXUnknown?

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 57:

> 55:   static void current_thread_init_wx();
> 56: 
> 57:   static void current_thread_assert_wx_state(WXMode expected);

Can we move all these into the ThreadWXEnable class so they are not in the os namespace? Even the enum could move - though it will make the use-sites a bit more verbose. I won't insist on pushing this WX stuff even deeper, but if anyone else thinks it is a good idea ... :)

src/hotspot/share/prims/jni.cpp line 97:

> 95: #include "utilities/macros.hpp"
> 96: #include "utilities/vmError.hpp"
> 97: #include "runtime/thread.inline.hpp"

Why do we need this? Why do we not include os.hpp?

src/hotspot/share/runtime/safefetch.inline.hpp line 31:

> 29: 
> 30: #include "runtime/stubRoutines.hpp"
> 31: #include "runtime/os.hpp"

Please list the includes alphabetically.

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

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

From duke at openjdk.java.net  Tue Mar  8 08:41:07 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 08:41:07 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v3]
In-Reply-To: <3-7lQJObHUh4005vGNqLqMg8SNxYcqXJPllqD3bGXjg=.6372dde6-2867-4045-ae02-cc952ebada50@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>
 <3-7lQJObHUh4005vGNqLqMg8SNxYcqXJPllqD3bGXjg=.6372dde6-2867-4045-ae02-cc952ebada50@github.com>
Message-ID: <pCx-cbZasEVJbtufIQYn2o7UFZrFsZMj7VgwOq-_cxI=.ab966cb8-e6eb-47df-b409-4ae74ebe17ca@github.com>

On Tue, 8 Mar 2022 03:51:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move WX functionality into os specific files
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 57:
> 
>> 55:   static void current_thread_init_wx();
>> 56: 
>> 57:   static void current_thread_assert_wx_state(WXMode expected);
> 
> Can we move all these into the ThreadWXEnable class so they are not in the os namespace? Even the enum could move - though it will make the use-sites a bit more verbose. I won't insist on pushing this WX stuff even deeper, but if anyone else thinks it is a good idea ... :)

I'm open for suggestions, but putting it there was the simplest way. The problem is that os is not a namespace, but a class. But this could and should probably be changed.

> src/hotspot/share/prims/jni.cpp line 97:
> 
>> 95: #include "utilities/macros.hpp"
>> 96: #include "utilities/vmError.hpp"
>> 97: #include "runtime/thread.inline.hpp"
> 
> Why do we need this? Why do we not include os.hpp?

We need this, because it does not compile (linker error) otherwise. But I forgot to include os.hpp (but included by thread.inline.hpp).

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

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

From dholmes at openjdk.java.net  Tue Mar  8 09:06:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 09:06:06 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v3]
In-Reply-To: <pCx-cbZasEVJbtufIQYn2o7UFZrFsZMj7VgwOq-_cxI=.ab966cb8-e6eb-47df-b409-4ae74ebe17ca@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>
 <3-7lQJObHUh4005vGNqLqMg8SNxYcqXJPllqD3bGXjg=.6372dde6-2867-4045-ae02-cc952ebada50@github.com>
 <pCx-cbZasEVJbtufIQYn2o7UFZrFsZMj7VgwOq-_cxI=.ab966cb8-e6eb-47df-b409-4ae74ebe17ca@github.com>
Message-ID: <ZPAnUPb7Lek9lZfKyzkBDki2Qo5WqWogPkvxXmlY8QY=.ac4b538c-3dd0-48f7-bde1-a657ed88187e@github.com>

On Tue, 8 Mar 2022 08:36:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 57:
>> 
>>> 55:   static void current_thread_init_wx();
>>> 56: 
>>> 57:   static void current_thread_assert_wx_state(WXMode expected);
>> 
>> Can we move all these into the ThreadWXEnable class so they are not in the os namespace? Even the enum could move - though it will make the use-sites a bit more verbose. I won't insist on pushing this WX stuff even deeper, but if anyone else thinks it is a good idea ... :)
>
> I'm open for suggestions, but putting it there was the simplest way. The problem is that os is not a namespace, but a class. But this could and should probably be changed.

I was suggesting pushing everything in to os::ThreadWXEnable class.

>> src/hotspot/share/prims/jni.cpp line 97:
>> 
>>> 95: #include "utilities/macros.hpp"
>>> 96: #include "utilities/vmError.hpp"
>>> 97: #include "runtime/thread.inline.hpp"
>> 
>> Why do we need this? Why do we not include os.hpp?
>
> We need this, because it does not compile (linker error) otherwise. But I forgot to include os.hpp (but included by thread.inline.hpp).

But you didn't add anything that needs it - in fact you deleted `thread->enable_wx` - so perhaps the linker error was from a different variant of the fix?

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

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

From duke at openjdk.java.net  Tue Mar  8 09:10:02 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 09:10:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v3]
In-Reply-To: <ZPAnUPb7Lek9lZfKyzkBDki2Qo5WqWogPkvxXmlY8QY=.ac4b538c-3dd0-48f7-bde1-a657ed88187e@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <UHvm6iYor0ENS7k_ewmY6O1IK95tFR04-uLAZ3W0Cb4=.ed635d2a-f73f-409e-9427-15899c638606@github.com>
 <3-7lQJObHUh4005vGNqLqMg8SNxYcqXJPllqD3bGXjg=.6372dde6-2867-4045-ae02-cc952ebada50@github.com>
 <pCx-cbZasEVJbtufIQYn2o7UFZrFsZMj7VgwOq-_cxI=.ab966cb8-e6eb-47df-b409-4ae74ebe17ca@github.com>
 <ZPAnUPb7Lek9lZfKyzkBDki2Qo5WqWogPkvxXmlY8QY=.ac4b538c-3dd0-48f7-bde1-a657ed88187e@github.com>
Message-ID: <vzzqHSTccprkFBsxMj_cAM1rzwMgK3RSytOBOucXXAk=.5684b719-aa58-4f38-aa70-538a3803988d@github.com>

On Tue, 8 Mar 2022 08:59:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm open for suggestions, but putting it there was the simplest way. The problem is that os is not a namespace, but a class. But this could and should probably be changed.
>
> I was suggesting pushing everything in to os::ThreadWXEnable class.

I don't think that this would be good as this would lead to fairly long calls. I would rather create a class wx and place everything in this (renaming ThreadWXEnable to Enable).

>> We need this, because it does not compile (linker error) otherwise. But I forgot to include os.hpp (but included by thread.inline.hpp).
>
> But you didn't add anything that needs it - in fact you deleted `thread->enable_wx` - so perhaps the linker error was from a different variant of the fix?

You're right. That's weird.

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

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

From duke at openjdk.java.net  Tue Mar  8 10:32:46 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 10:32:46 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:

 - Move code to os::current_thread_wx
 - Small fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7727/files
  - new: https://git.openjdk.java.net/jdk/pull/7727/files/a7c38e52..02048306

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

  Stats: 100 lines in 28 files changed: 15 ins; 11 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7727/head:pull/7727

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

From duke at openjdk.java.net  Tue Mar  8 12:10:00 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 12:10:00 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
Message-ID: <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>

On Tue, 8 Mar 2022 10:32:46 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move code to os::current_thread_wx
>  - Small fixes

I don't know why the Linux x86 build fails.

I tested the current version with code related to #7591 and it seems to fix the remaining problems (I tested it also with NMT enabled).

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

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

From dholmes at openjdk.java.net  Tue Mar  8 12:39:12 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 12:39:12 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
Message-ID: <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>

On Tue, 8 Mar 2022 10:32:46 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move code to os::current_thread_wx
>  - Small fixes

The Linux x86 build failure is not related to this and has already been fixed, so you should re-sync with master branch.

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45:

> 43:   #ifdef __APPLE__
> 44: 
> 45:   class current_thread_wx {

This violates the style guide for class names. It would be CurrentThreadWX - but ThreadWX seems sufficient to me.

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

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

From duke at openjdk.java.net  Tue Mar  8 13:11:06 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 13:11:06 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
Message-ID: <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>

On Tue, 8 Mar 2022 12:33:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move code to os::current_thread_wx
>>  - Small fixes
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45:
> 
>> 43:   #ifdef __APPLE__
>> 44: 
>> 45:   class current_thread_wx {
> 
> This violates the style guide for class names. It would be CurrentThreadWX - but ThreadWX seems sufficient to me.

But os is okay? I just use this name for grouping.

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

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

From duke at openjdk.java.net  Tue Mar  8 13:17:29 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Tue, 8 Mar 2022 13:17:29 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v5]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <j6lIZfs2esGbQPvy3B80N_3eS5Dz9dq2HXYFYMv65cM=.f0bf9a32-5c04-4c6b-b469-26560b9fa4f4@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Move code to os::current_thread_wx
 - Small fixes
 - Move WX functionality into os specific files
 - Minor fixes
 - Fix include for threadWXSetters.inline.hpp
 - Remove thread parameter from ThreadWXEnable
 - Remove thread parameter from os methods
 - Remove wx_init and current thread assert in safefetch
 - Use os::current_thread_change_wx instead of thread methods

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

Changes: https://git.openjdk.java.net/jdk/pull/7727/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7727&range=04
  Stats: 241 lines in 32 files changed: 52 ins; 111 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7727/head:pull/7727

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

From redestad at openjdk.java.net  Tue Mar  8 13:54:02 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 8 Mar 2022 13:54:02 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v11]
In-Reply-To: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com>
Message-ID: <ltjd8LkRbOaAQ3JnWVvx4BuEzLzw_cJ2ip5m7jdYFqc=.d128874a-a44b-4d22-859e-bd81d572fab9@github.com>

On Mon, 7 Mar 2022 23:13:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use 32-bit mask to calculate correct remainder value
>  - ary1 not required to have USE_KILL effect

aarch64: https://jmh.morethan.io/?gists=281ac3c29ef85f9f64c0440cd7f8c247,0a2c7d3b803f9cd5799f6af95eb6a90a

Brings decent gains on the "sunshine case" and the mixed microbenchmarks, but there are a few glaring exceptions which I'm still investigating.

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

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

From mdoerr at openjdk.java.net  Tue Mar  8 17:29:07 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 8 Mar 2022 17:29:07 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v11]
In-Reply-To: <d48UorB5acC36n36zS7Ky0hFOArniVDdMi5a80s4OT4=.7581eef2-5724-4c19-8190-a1c8d53746c8@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <d48UorB5acC36n36zS7Ky0hFOArniVDdMi5a80s4OT4=.7581eef2-5724-4c19-8190-a1c8d53746c8@github.com>
Message-ID: <swzSzp3gMDztVYbidFW5-z_nVZgPlG951NwiexgaaLw=.87268ec1-c867-47aa-aad5-ce4293fc5df3@github.com>

On Thu, 2 Sep 2021 16:06:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
>> 
>> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
>> 
>> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
>> 
>> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
>> 
>> Before:
>> 
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
>> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
>> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
>> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
>> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
>> 
>> 
>> After:
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
>> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
>> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
>> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
>> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 `tier1` with Shenandoah
>>  - [x] Linux AArch64 `tier1` with Shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More natural order of arguments
>  - Move the fwdptr-related updaters to ShenandoahForwarding
>  - Avoid acq_rel that is promoted to seq_cst on ARM <8.3

Is this PR still planned?
Should we test it on PPC64?

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

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

From lucy at openjdk.java.net  Tue Mar  8 20:15:05 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 8 Mar 2022 20:15:05 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v11]
In-Reply-To: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com>
Message-ID: <jofVVcgNEpmMEsLrbZYLi8w850T8yY712scUBzA17ck=.847ea994-1502-4c45-bd29-71db7208a573@github.com>

On Mon, 7 Mar 2022 23:13:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use 32-bit mask to calculate correct remainder value
>  - ary1 not required to have USE_KILL effect

Changes look good. 
Due to lack of specific expertise, I can't fully approve aarch64 and x86 changes.

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

Marked as reviewed by lucy (Reviewer).

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

From kdnilsen at openjdk.java.net  Wed Mar  9 00:07:54 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 9 Mar 2022 00:07:54 GMT
Subject: RFR: Revert "Mutator may fail to evacuate"
Message-ID: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>

This reverts commit 2132a6d151e4c46b71a220100fa478a8be676f13.

We found that the solution implemented in this commit is insufficient to address the problem.  We need to redesign the OOM protocol for evacuation allocation failures.  This is being explored by other engineers.

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

Commit messages:
 - Revert "Mutator may fail to evacuate"

Changes: https://git.openjdk.java.net/shenandoah/pull/123/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=123&range=00
  Stats: 12 lines in 1 file changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/123/head:pull/123

PR: https://git.openjdk.java.net/shenandoah/pull/123

From wkemper at openjdk.java.net  Wed Mar  9 00:07:54 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 9 Mar 2022 00:07:54 GMT
Subject: RFR: Revert "Mutator may fail to evacuate"
In-Reply-To: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
References: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
Message-ID: <NBosoHYBCGwb8_MDq9y2h3dK0RO1rXU9EYEyZaD20Rc=.318ffdcd-cbb7-472e-922c-932fbd41649d@github.com>

On Tue, 8 Mar 2022 23:58:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reverts commit 2132a6d151e4c46b71a220100fa478a8be676f13.
> 
> We found that the solution implemented in this commit is insufficient to address the problem.  We need to redesign the OOM protocol for evacuation allocation failures.  This is being explored by other engineers.

Marked as reviewed by wkemper (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/123

From stuefe at openjdk.java.net  Wed Mar  9 06:52:58 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Mar 2022 06:52:58 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
 <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
Message-ID: <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>

On Tue, 8 Mar 2022 13:08:13 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 45:
>> 
>>> 43:   #ifdef __APPLE__
>>> 44: 
>>> 45:   class current_thread_wx {
>> 
>> This violates the style guide for class names. It would be CurrentThreadWX - but ThreadWX seems sufficient to me.
>
> But os is okay? I just use this name for grouping.

"os" is okay. Its historical. Its also more of a namespace really.

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

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

From duke at openjdk.java.net  Wed Mar  9 07:04:00 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 07:04:00 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
 <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
 <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>
Message-ID: <RxEOn1fyyRFwpqpJuihjF-7T3pezElcKqnQxl0Eigp8=.441576fe-4a54-41c8-b951-2863270a8432@github.com>

On Wed, 9 Mar 2022 06:49:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> But os is okay? I just use this name for grouping.
>
> "os" is okay. Its historical. Its also more of a namespace really.

but current_thread_wx would be too? Maybe I could change both to namespaces?

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

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

From duke at openjdk.java.net  Wed Mar  9 07:04:00 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 07:04:00 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <RxEOn1fyyRFwpqpJuihjF-7T3pezElcKqnQxl0Eigp8=.441576fe-4a54-41c8-b951-2863270a8432@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
 <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
 <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>
 <RxEOn1fyyRFwpqpJuihjF-7T3pezElcKqnQxl0Eigp8=.441576fe-4a54-41c8-b951-2863270a8432@github.com>
Message-ID: <l0Fcaqh-0Ji3h_wY_SprcuakVoVyH1qahSOx3-C8AHY=.b84aaa1e-f86e-45fc-92a0-a2b0a7f980ae@github.com>

On Wed, 9 Mar 2022 07:00:29 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> "os" is okay. Its historical. Its also more of a namespace really.
>
> but current_thread_wx would be too? Maybe I could change both to namespaces?

But the style guide has no opinions on them...

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

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

From dholmes at openjdk.java.net  Wed Mar  9 07:34:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Mar 2022 07:34:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
Message-ID: <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>

On Tue, 8 Mar 2022 12:07:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> Johannes Bechberger has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> I don't know why the Linux x86 build fails.
> 
> I tested the current version with code related to #7591 and it seems to fix the remaining problems (I tested it also with NMT enabled).

@parttimenerd  please never force-push in an active review as it completely destroys the review history and comment context!

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

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

From dholmes at openjdk.java.net  Wed Mar  9 07:34:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Mar 2022 07:34:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <l0Fcaqh-0Ji3h_wY_SprcuakVoVyH1qahSOx3-C8AHY=.b84aaa1e-f86e-45fc-92a0-a2b0a7f980ae@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
 <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
 <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>
 <RxEOn1fyyRFwpqpJuihjF-7T3pezElcKqnQxl0Eigp8=.441576fe-4a54-41c8-b951-2863270a8432@github.com>
 <l0Fcaqh-0Ji3h_wY_SprcuakVoVyH1qahSOx3-C8AHY=.b84aaa1e-f86e-45fc-92a0-a2b0a7f980ae@github.com>
Message-ID: <sRXwzN3sHhvEHGnohmSk1uyp7_w1P2QOMr6--9mUIwE=.9182e9cd-cf2b-41f0-b30e-e64d272c2a40@github.com>

On Wed, 9 Mar 2022 07:01:06 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> but current_thread_wx would be too? Maybe I could change both to namespaces?
>
> But the style guide has no opinions on them...

If/when the styleguide has an opinion on namespaces I would expect the same naming style to apply as for Classes.

Hotspot is full of historical quirks like "class os" I'm afraid.

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

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

From duke at openjdk.java.net  Wed Mar  9 08:20:05 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 08:20:05 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v5]
In-Reply-To: <j6lIZfs2esGbQPvy3B80N_3eS5Dz9dq2HXYFYMv65cM=.f0bf9a32-5c04-4c6b-b469-26560b9fa4f4@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <j6lIZfs2esGbQPvy3B80N_3eS5Dz9dq2HXYFYMv65cM=.f0bf9a32-5c04-4c6b-b469-26560b9fa4f4@github.com>
Message-ID: <_MOmqVYDaAuWfkuGPnPfm10pUCWb0nbH7fedPf4llSo=.7288c328-7ce5-4537-9a88-7b1c989f3f55@github.com>

On Tue, 8 Mar 2022 13:17:29 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Move code to os::current_thread_wx
>  - Small fixes
>  - Move WX functionality into os specific files
>  - Minor fixes
>  - Fix include for threadWXSetters.inline.hpp
>  - Remove thread parameter from ThreadWXEnable
>  - Remove thread parameter from os methods
>  - Remove wx_init and current thread assert in safefetch
>  - Use os::current_thread_change_wx instead of thread methods

Oh, I did not know that. Sorry for that, I just wanted to rebase it and forgot that this would change all the commit ids.

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

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

From duke at openjdk.java.net  Wed Mar  9 08:35:41 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 08:35:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  current_thread_wx -> ThreadWX

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7727/files
  - new: https://git.openjdk.java.net/jdk/pull/7727/files/21dd0046..f206e6d2

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

  Stats: 61 lines in 28 files changed: 0 ins; 0 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7727/head:pull/7727

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

From duke at openjdk.java.net  Wed Mar  9 08:35:42 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 08:35:42 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <sRXwzN3sHhvEHGnohmSk1uyp7_w1P2QOMr6--9mUIwE=.9182e9cd-cf2b-41f0-b30e-e64d272c2a40@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <zamROIohCzz3rsNJrmSMNfixraBhy9BXiwjfOFgSD-U=.04f21dbd-c616-447e-87e0-f61cc9b7b1b6@github.com>
 <DV0qBl7-1NUNUHMzmc4OkRkp3Hk3IkBU2F44_FKCpro=.d26b3c1a-be53-4cd9-a32a-4a46bf98782d@github.com>
 <AfHtcLhM-r4HwDhsbrw2zoQOU0ccNTPGoEopDGdOht8=.97717e8d-3412-4da0-bdad-de777ee41586@github.com>
 <RxEOn1fyyRFwpqpJuihjF-7T3pezElcKqnQxl0Eigp8=.441576fe-4a54-41c8-b951-2863270a8432@github.com>
 <l0Fcaqh-0Ji3h_wY_SprcuakVoVyH1qahSOx3-C8AHY=.b84aaa1e-f86e-45fc-92a0-a2b0a7f980ae@github.com>
 <sRXwzN3sHhvEHGnohmSk1uyp7_w1P2QOMr6--9mUIwE=.9182e9cd-cf2b-41f0-b30e-e64d272c2a40@github.com>
Message-ID: <58tuExRUjjGeYwpYnN14FywexGhLde7PLxdaBqyCMfM=.ee1f9800-85a4-441c-b289-fc4653c1843b@github.com>

On Wed, 9 Mar 2022 07:28:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> But the style guide has no opinions on them...
>
> If/when the styleguide has an opinion on namespaces I would expect the same naming style to apply as for Classes.
> 
> Hotspot is full of historical quirks like "class os" I'm afraid.

I changed it.

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

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

From stuefe at openjdk.java.net  Wed Mar  9 08:40:07 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Mar 2022 08:40:07 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v5]
In-Reply-To: <_MOmqVYDaAuWfkuGPnPfm10pUCWb0nbH7fedPf4llSo=.7288c328-7ce5-4537-9a88-7b1c989f3f55@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <j6lIZfs2esGbQPvy3B80N_3eS5Dz9dq2HXYFYMv65cM=.f0bf9a32-5c04-4c6b-b469-26560b9fa4f4@github.com>
 <_MOmqVYDaAuWfkuGPnPfm10pUCWb0nbH7fedPf4llSo=.7288c328-7ce5-4537-9a88-7b1c989f3f55@github.com>
Message-ID: <ebJkOqlD-JMFsATSbRkKXyb44qC5Tjvec7xCPDmVaLo=.f16e6b91-6783-4176-8d87-01345ba72758@github.com>

On Wed, 9 Mar 2022 08:16:51 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Oh, I did not know that. Sorry for that, I just wanted to rebase it and forgot that this would change all the commit ids.

You couldn't know. Just merge "master", which achieves the same and leaves the history intact.

Additional tip. You can start a PR in draft mode. Reviews won't start until you un-draft. In draft mode, you have plenty of time to flesh out the patch and fix all bugs that show up in GHAs. In that phase, it's still okay to rebase. Once you consider the patch ready, you can un-draft the PR and the reviews start. Only then you should not rebase anymore.

Starting out with a draft PR has also the advantage of not using reviewer time on an incomplete patch.

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

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

From stuefe at openjdk.java.net  Wed Mar  9 10:15:07 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Mar 2022 10:15:07 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
 <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>
Message-ID: <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>

On Wed, 9 Mar 2022 07:30:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I don't know why the Linux x86 build fails.
>> 
>> I tested the current version with code related to #7591 and it seems to fix the remaining problems (I tested it also with NMT enabled).
>
> @parttimenerd  please never force-push in an active review as it completely destroys the review history and comment context!

Hi @dholmes-ora , @parttimenerd 

I'd like to argue again for my proposal from before.

All this is contrary to how we deal with platform dependencies normally. Normally,  we
1) either keep the whole code in platform specific places - including callers. If that is possible.
2) If there are very few callers in shared places, we keep implementation in platform branch and #ifdef the callsites in shared code out to the affected platforms
3) If there are many callers in shared code or if it looks like it may be useful on other platforms too at some point, we usually wrap the logic in a platform generic function behind a descriptive name, which we stub out for the unaffected platforms.

(3) is very common.

My proposal from before would make it possible to really hide all WX logic from shared code:

shared/runtime/os.hpp
``` 
class os {
...
// Platform specific hook to prepare the current thread for calling generated code
void enable_jit_calls_for_current_thread() NOT_MACOS_AARCH64({})
// Platform specific hook to clean up the current thread after calling into generated code
void disable_jit_calls_for_current_thread() NOT_MACOS_AARCH64({})

class ThreadEnableJitCallsMark: public StackObj {
public:
	ThreadEnableJitCallsMark() { enable_jit_calls_for_current_thread(); }
	~ThreadEnableJitCallsMark() { disable_jit_calls_for_current_thread(); }
}



(ThreadEnableJitCallsMark could be optionally spread out into separate include)


os.bsd_aarch64.cpp

void os::enable_jit_calls_for_current_thread() {
 ... blabla ... pthread_jit_write_protect_np();
}

void os::disable_jit_calls_for_current_thread() {
 ... blabla ... pthread_jit_write_protect_np();
}



Thats very little code. It effectively hides all platform details where they belong, away from shared code. In shared code, you use either one of `os::(enable|disable)_jit_calls_for_current_thread()` or the companion `os::ThreadEnableJitCallsMark`. Advantages would be:

- Call sites in shared code are now easier to mentally parse. `os::disable_jit_calls_for_current_thread()` is much clearer than `MACOS_AARCH64_ONLY(os::ThreadWX::Enable __wx(os::ThreadWX::Write));`.
- We don't need MAC_AARCH64_ONLY in shared code
- We don't need the enums in shared code. Dont need to understand what they do, nor the difference between "Write" and "Exec". 

Side note, I'd also suggest a different name for the RAII object to something like "xxxMark". That is more according to hotspot customs.

----

Cheers, Thomas

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

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

From dholmes at openjdk.java.net  Wed Mar  9 11:03:08 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Mar 2022 11:03:08 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
 <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>
 <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>
Message-ID: <0JaqT9Wqyj0RuIFJFGGXOdL6471wKfu8EP0_WjcbwG8=.d50bf928-ce4d-4fea-8d4d-491f1e01b4d7@github.com>

On Wed, 9 Mar 2022 10:11:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @parttimenerd  please never force-push in an active review as it completely destroys the review history and comment context!
>
> Hi @dholmes-ora , @parttimenerd 
> 
> I'd like to argue again for my proposal from before.
> 
> All this is contrary to how we deal with platform dependencies normally. Normally,  we
> 1) either keep the whole code in platform specific places - including callers. If that is possible.
> 2) If there are very few callers in shared places, we keep implementation in platform branch and #ifdef the callsites in shared code out to the affected platforms
> 3) If there are many callers in shared code or if it looks like it may be useful on other platforms too at some point, we usually wrap the logic in a platform generic function behind a descriptive name, which we stub out for the unaffected platforms.
> 
> (3) is very common.
> 
> My proposal from before would make it possible to really hide all WX logic from shared code:
> 
> shared/runtime/os.hpp
> ``` 
> class os {
> ...
> // Platform specific hook to prepare the current thread for calling generated code
> void enable_jit_calls_for_current_thread() NOT_MACOS_AARCH64({})
> // Platform specific hook to clean up the current thread after calling into generated code
> void disable_jit_calls_for_current_thread() NOT_MACOS_AARCH64({})
> 
> class ThreadEnableJitCallsMark: public StackObj {
> public:
> 	ThreadEnableJitCallsMark() { enable_jit_calls_for_current_thread(); }
> 	~ThreadEnableJitCallsMark() { disable_jit_calls_for_current_thread(); }
> }
> 
> 
> 
> (ThreadEnableJitCallsMark could be optionally spread out into separate include)
> 
> 
> os.bsd_aarch64.cpp
> 
> void os::enable_jit_calls_for_current_thread() {
>  ... blabla ... pthread_jit_write_protect_np();
> }
> 
> void os::disable_jit_calls_for_current_thread() {
>  ... blabla ... pthread_jit_write_protect_np();
> }
> 
> 
> 
> Thats very little code. It effectively hides all platform details where they belong, away from shared code. In shared code, you use either one of `os::(enable|disable)_jit_calls_for_current_thread()` or the companion `os::ThreadEnableJitCallsMark`. Advantages would be:
> 
> - Call sites in shared code are now easier to mentally parse. `os::disable_jit_calls_for_current_thread()` is much clearer than `MACOS_AARCH64_ONLY(os::ThreadWX::Enable __wx(os::ThreadWX::Write));`.
> - We don't need MAC_AARCH64_ONLY in shared code
> - We don't need the enums in shared code. Dont need to understand what they do, nor the difference between "Write" and "Exec". 
> 
> Side note, I'd also suggest a different name for the RAII object to something like "xxxMark". That is more according to hotspot customs.
> 
> ----
> 
> Cheers, Thomas

@tstuefe  do you have some examples of (3)? I don't like introducing a fake, seemingly general-purpose, API for something that is very much platform specific. I do dislike intensely the way the ThreadWX changes pollute shared code, and as has been said in other reviews of that code, there really should be a much cleaner/clearer place where these transitions occur - if we can find it.

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

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

From duke at openjdk.java.net  Wed Mar  9 11:21:02 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 11:21:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
 <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>
 <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>
Message-ID: <H5t1K5xuMhYybXPk6z-VjdyOw7Zsrp25JiOYqCNsmzM=.f5f9c783-184c-4529-8988-71ceb73685a3@github.com>

On Wed, 9 Mar 2022 10:11:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Call sites in shared code are now easier to mentally parse. os::disable_jit_calls_for_current_thread() is much clearer than MACOS_AARCH64_ONLY(os::ThreadWX::Enable __wx(os::ThreadWX::Write));

That's not enough, as I wrote before, the RAII object is still needed for nesting. But I agree, that using better names would improve readability (like having two RAII objects for specific purposes).

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

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

From dholmes at openjdk.java.net  Wed Mar  9 11:27:01 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 9 Mar 2022 11:27:01 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <vDLq4fCD1hbvjOGoTIxn5LRlyKin4imoaYU1f-QZXXw=.8958e020-c44b-4dfc-86d6-ab37ca3949fe@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

A couple of minor nits but otherwise I'm okay with this version.

Thanks,
David

src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp line 35:

> 33: #include "prims/jvmtiExport.hpp"
> 34: #include "runtime/safepoint.hpp"
> 35: #include "runtime/thread.inline.hpp"

I still don't see why this is needed.

src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp line 77:

> 75: template<int BType, typename JniType = decltype(BasicTypeToJni<BType>::jni_type)>
> 76: JniType static_fast_get_field_wrapper(JNIEnv *env, jobject obj, jfieldID fieldID) {
> 77:   JavaThread* thread = JavaThread::thread_from_jni_environment(env);

This line is no longer needed.

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

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

From duke at openjdk.java.net  Wed Mar  9 11:27:02 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 11:27:02 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <vDLq4fCD1hbvjOGoTIxn5LRlyKin4imoaYU1f-QZXXw=.8958e020-c44b-4dfc-86d6-ab37ca3949fe@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <vDLq4fCD1hbvjOGoTIxn5LRlyKin4imoaYU1f-QZXXw=.8958e020-c44b-4dfc-86d6-ab37ca3949fe@github.com>
Message-ID: <C48KSJ4zLhpY3zaA6VFuckCyvJS1PviQjuqNhXuu0Fs=.390c7d3b-cfb4-44c4-8096-1d42f9c2eb86@github.com>

On Wed, 9 Mar 2022 11:14:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   current_thread_wx -> ThreadWX
>
> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp line 35:
> 
>> 33: #include "prims/jvmtiExport.hpp"
>> 34: #include "runtime/safepoint.hpp"
>> 35: #include "runtime/thread.inline.hpp"
> 
> I still don't see why this is needed.

I must have forgotten this line during refactoring.

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

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

From stuefe at openjdk.java.net  Wed Mar  9 11:55:05 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Mar 2022 11:55:05 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v4]
In-Reply-To: <0JaqT9Wqyj0RuIFJFGGXOdL6471wKfu8EP0_WjcbwG8=.d50bf928-ce4d-4fea-8d4d-491f1e01b4d7@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <2emw-rdoUshgEurchU32RBqIHeWVqvD9ZCDTxq-QExg=.b20d6f6e-1bd9-4f49-84af-6c6f80ae1c7f@github.com>
 <e9BW0qH3i21g-h3r7eqGhA3A5V04nNeqa0AkFNmuaF8=.46ce25bf-e421-4e93-8a1d-7850134b9f89@github.com>
 <ejBCLSxZEURn3OADVtPW-O25bioO1pVTVdCibnqOUS0=.50569131-920a-4734-810f-74bcf1941002@github.com>
 <M5oEYS7KN3on_De3lo6H48QyVpcjXtXLsh_LAgInZ-E=.cd13e476-df5c-47f9-a84c-a3ab9ff9da22@github.com>
 <0JaqT9Wqyj0RuIFJFGGXOdL6471wKfu8EP0_WjcbwG8=.d50bf928-ce4d-4fea-8d4d-491f1e01b4d7@github.com>
Message-ID: <-3iFQkq7PJ6VpX9rCset1xvOiD4UAWRwaaeCX5Uh4r0=.89cd0175-2d12-4f85-ac0a-1b3e6b5a3351@github.com>

On Wed, 9 Mar 2022 11:00:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @tstuefe do you have some examples of (3)? I don't like introducing a fake, seemingly general-purpose, API for something that is very much platform specific. I do dislike intensely the way the ThreadWX changes pollute shared code, and as has been said in other reviews of that code, there really should be a much cleaner/clearer place where these transitions occur - if we can find it.

Examples for platform specifics hidden behind a common facade with one or two platforms missing are very common, but I assume you mean implementations that are stubbed out almost everywhere, right?

 "os::os_exception_wrapper" is a very good example, hiding the details of SEH - which only exists on Windows - from generic code. It is an empty stub implementation on all platforms but Windows x86. On all other platforms (including windows aarch) we don't have that facility.

- "os::breakpoint" is a bit similar, since native breakpoint support only exists on Windows

- "os::set_native_thread_name" used to initially only exist on windows and linux, leaving out aix, mac and solaris.

I can dig deeper, but I remember generic wrappers with only a few or only one platform implementation being around. Especially when we still had Solaris around. 

I remember because like you I never was too fond of that pattern, but I find it often the smaller evil.

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

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

From akozlov at openjdk.java.net  Wed Mar  9 16:38:07 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 9 Mar 2022 16:38:07 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <hfk9Yad0zPos61W45L9ss11DBOUj5rV8jn16uKIqcqQ=.ae7838aa-3620-4fdc-a875-56a51ef48878@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

The change proposes to assume WXWrite as the initial state. Have you considered to extend ThreadWXEnable to fix the assert failure? Something like below (I have not tried to compile though). The refactoring looks OK, but it makes sense to separate it from functional change.


class ThreadWXEnable  {
  Thread* _thread;
  WXMode _old_mode;

public:
  ThreadWXEnable(WXMode new_mode, Thread* thread) :
    _thread(thread)
  {
    if (_thread) {
      _old_mode = _thread->enable_wx(new_mode);
    } else {
      os::current_thread_enable_wx(new_mode);
      _old_mode = WXWrite;
    }
  }
  ~ThreadWXEnable() {
    if (_thread) {
      _thread->enable_wx(_old_mode);
    } else {
      os::current_thread_enable_wx(_old_mode);
    }
  }
};

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

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

From duke at openjdk.java.net  Wed Mar  9 16:47:04 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 16:47:04 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <Nf9n4aK8P9Fzdrh0ZgmFFyZ5r4qxk-fYKs-IES92iLM=.420e7624-d7dd-4dae-be5f-0bfe7e6e8cb0@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

This probably does not work as intended, as it would prevent nesting of ThreadWXEnable before a thread exists. I already proposed a version without any refactoring (just moving the current WXMode from Thread into os near the related methods): https://github.com/openjdk/jdk/pull/7727/commits/478ec1a7ca2c72e5916b28613a4875aa2ee1a793 (state at this commit).

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

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

From redestad at openjdk.java.net  Wed Mar  9 16:52:54 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 16:52:54 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v12]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <hquQ4jRlCQ9-CBuwfPlLNn1Ro0m8aMfQiXmZMK2kNuE=.539e5abe-6576-4513-935c-46ffa6d64f6b@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Restructure encodeUTF8 to reduce code gen issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/934b5b8a..3d155c87

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=10-11

  Stats: 21 lines in 1 file changed: 8 ins; 5 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From akozlov at openjdk.java.net  Wed Mar  9 19:06:51 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 9 Mar 2022 19:06:51 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

https://github.com/openjdk/jdk/compare/master...478ec1a7ca2c72e5916b28613a4875aa2ee1a793 touches more places than a targeted change in ThreadWXEnable... I'm not sure the real nesting is required for a thread that is not registered properly with VM. The initial state is always assumed for the NULL Thread. The SafeFetch assembly does not do up-calls to VM. I don't see why we'd need runtime tracking of WX state. The state is either WXExec for SafeFetch assembly, or unknown -- which we assume to be WXWrite regardless of approach taken.

Nesting was implemented to reduce the amount of changes in JVM (yes, WX code scattered around the VM less than it could be :)), but it is possible to avoid runtime WX tracking if you always know the state, like we do if Thread == NULL.

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

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

From duke at openjdk.java.net  Wed Mar  9 20:28:41 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Wed, 9 Mar 2022 20:28:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <bq7COCxcwcLZ0-wIdVuz2sSrVpdNr4SMAA3t5wrbnEc=.a2fbccbd-e51c-4067-ba47-ef0caf048394@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

Interesting. But I would nonetheless create an assertion that checks that there is no nesting in the case without a Thread object. I would this using a thread local nesting counter in the ThreadWXEnable class (incremented in the constructor and decremented in the destructor).

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

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

From redestad at openjdk.java.net  Wed Mar  9 20:56:46 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 20:56:46 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v12]
In-Reply-To: <hquQ4jRlCQ9-CBuwfPlLNn1Ro0m8aMfQiXmZMK2kNuE=.539e5abe-6576-4513-935c-46ffa6d64f6b@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <hquQ4jRlCQ9-CBuwfPlLNn1Ro0m8aMfQiXmZMK2kNuE=.539e5abe-6576-4513-935c-46ffa6d64f6b@github.com>
Message-ID: <vXvh4Llpx3MgFtqAWP5e5WCVW9SgsYSZRLvKgLFhK7I=.d804d0c7-c9c8-41a2-929e-068ec18c87bb@github.com>

On Wed, 9 Mar 2022 16:52:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restructure encodeUTF8 to reduce code gen issues

The regressions I observe on aarch64 in `encodeLatin1Short` and a few others are not in the intrinsic itself but due changes to the surrounding code. Reverting the changes to `String.encodeUTF8` removes the regressions (but also the improvements).  Seems some loop optimization is not taking place like it should - or just differently. Going back to check I see that x64 is also affected, meaning this is something that has come in when syncing up with master. 

I've experimented with adjusting the code to try and workaround and improve code gen, but with only partial success. I'll back out the changes to `String.encodeUTF8`, see if we can deal with the loop opt regression (separately) and return to do the `encodeUTF8` optimization later on.

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

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

From redestad at openjdk.java.net  Wed Mar  9 21:01:13 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 21:01:13 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v13]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <oDKdbT31MA4d2rWukTULoIsgNzNRynaX2HyZjCyDBbw=.e13c5d9c-187b-4da3-8a1e-bf32b3104bdd@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' into count_positives
 - Restructure encodeUTF8 to reduce code gen issues
 - use 32-bit mask to calculate correct remainder value
 - ary1 not required to have USE_KILL effect
 - Better implementation for aarch64 returning roughly the count of positive bytes
 - Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes)
 - Clean out and remove vmIntrinsics::_hasNegatives and all related code
 - s390 impl provided by @RealLucy
 - PPC impl provided by @TheRealMDoerr
 - Narrow the bottom_type of CountPositivesNode (always results in a positive int value)
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/ff766204...30739e15

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

Changes: https://git.openjdk.java.net/jdk/pull/7231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=12
  Stats: 638 lines in 36 files changed: 288 ins; 62 del; 288 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231

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

From redestad at openjdk.java.net  Wed Mar  9 23:44:22 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 23:44:22 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v14]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <t7_7m5Z9sO-rrqy_IWT28v09XKJuCgX-J_R6DJRqe54=.b894c926-11b6-4e21-8090-b946b3531b20@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Revert encodeUTF8 for this PR due issues with fragile optimization

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/30739e15..58ee73bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=12-13

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

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

From redestad at openjdk.java.net  Wed Mar  9 23:52:44 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 23:52:44 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v14]
In-Reply-To: <t7_7m5Z9sO-rrqy_IWT28v09XKJuCgX-J_R6DJRqe54=.b894c926-11b6-4e21-8090-b946b3531b20@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <t7_7m5Z9sO-rrqy_IWT28v09XKJuCgX-J_R6DJRqe54=.b894c926-11b6-4e21-8090-b946b3531b20@github.com>
Message-ID: <kp1ZExhz4IJ4h9z3WxDyRAxFciPBCQP2eMJ0Wj1SgmQ=.4116c3da-b832-458b-b995-8710b1810625@github.com>

On Wed, 9 Mar 2022 23:44:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert encodeUTF8 for this PR due issues with fragile optimization

Reverting changes to `String.encodeUTF8` brought all `encode`-micros down to effectively no change: https://jmh.morethan.io/?gist=b957cb9457c31141ac71d47f2e10486a (which proves implementing `hasNegatives` using `countPositives != len` has no measurable cost)

I consider this the final version for this PR (assuming tests pass). I need someone to review the aarch64 changes in particular, and perhaps someone from the core library team should sign off on the String changes (less of those now).

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

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

From redestad at openjdk.java.net  Wed Mar  9 23:59:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 9 Mar 2022 23:59:32 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v15]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright year in new test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/58ee73bb..bc5a8c80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=13-14

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

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

From stuefe at openjdk.java.net  Thu Mar 10 05:55:39 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Mar 2022 05:55:39 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
Message-ID: <7MNCDtaPTnKWN2k1DfuEUf8RIcQza2I2Q4IUa7Nm8Qs=.cb1605ee-2fab-4a49-b726-9bcf2b62c76a@github.com>

On Wed, 9 Mar 2022 19:03:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   current_thread_wx -> ThreadWX
>
> https://github.com/openjdk/jdk/compare/master...478ec1a7ca2c72e5916b28613a4875aa2ee1a793 touches more places than a targeted change in ThreadWXEnable... I'm not sure the real nesting is required for a thread that is not registered properly with VM. The initial state is always assumed for the NULL Thread. The SafeFetch assembly does not do up-calls to VM. I don't see why we'd need runtime tracking of WX state. The state is either WXExec for SafeFetch assembly, or unknown -- which we assume to be WXWrite regardless of approach taken.
> 
> Nesting was implemented to reduce the amount of changes in JVM (yes, WX code scattered around the VM less than it could be :)), but it is possible to avoid runtime WX tracking if you always know the state, like we do if Thread == NULL.

@AntonKozlov can you give us please a bit more background about the wx state stuff?

- Why don't we just switch it on once, for a thread that conceivably may call into generated code, and be done with? Why is this fine granular switching even needed? I find it difficult to imagine an attack vector that exploits having this always enabled for a thread. After all, we have to mark code cache with MAP_JIT already, so it is not like we can execute arbitrary memory ranges.
- Related to that, how much does this call cost? Is this a runtime call into the pthread library or does it get inlined somehow? Because things like SafeFetch are trimmed to be super cheap if the memory can be accessed. Doing a pthread call on every invocation may throw off the cost benefit ratio.
- Why and where do we need nesting? This would be so much easier if we could just not care.

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

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

From stuefe at openjdk.java.net  Thu Mar 10 06:04:42 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Mar 2022 06:04:42 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
Message-ID: <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>

On Wed, 9 Mar 2022 19:03:16 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   current_thread_wx -> ThreadWX
>
> https://github.com/openjdk/jdk/compare/master...478ec1a7ca2c72e5916b28613a4875aa2ee1a793 touches more places than a targeted change in ThreadWXEnable... I'm not sure the real nesting is required for a thread that is not registered properly with VM. The initial state is always assumed for the NULL Thread. The SafeFetch assembly does not do up-calls to VM. I don't see why we'd need runtime tracking of WX state. The state is either WXExec for SafeFetch assembly, or unknown -- which we assume to be WXWrite regardless of approach taken.
> 
> Nesting was implemented to reduce the amount of changes in JVM (yes, WX code scattered around the VM less than it could be :)), but it is possible to avoid runtime WX tracking if you always know the state, like we do if Thread == NULL.

Hi @AntonKozlov,

> [master...478ec1a](https://github.com/openjdk/jdk/compare/master...478ec1a7ca2c72e5916b28613a4875aa2ee1a793) touches more places than a targeted change in ThreadWXEnable... I'm not sure the real nesting is required for a thread that is not registered properly with VM.

Arguably we should restore, upon leaving the VM, the state that has been present before. Because a native thread may already have modified the wx state and overruling it is just rude. But I offhand don't see a way to do this since we have no way (?) to query the current state.



> The change proposes to assume WXWrite as the initial state. Have you considered to extend ThreadWXEnable to fix the assert failure? Something like below (I have not tried to compile though). The refactoring looks OK, but it makes sense to separate it from functional change.
> 
> ```
> class ThreadWXEnable  {
>   Thread* _thread;
>   WXMode _old_mode;
> 
> public:
>   ThreadWXEnable(WXMode new_mode, Thread* thread) :
>     _thread(thread)
>   {
>     if (_thread) {
>       _old_mode = _thread->enable_wx(new_mode);
>     } else {
>       os::current_thread_enable_wx(new_mode);
>       _old_mode = WXWrite;
>     }
>   }
>   ~ThreadWXEnable() {
>     if (_thread) {
>       _thread->enable_wx(_old_mode);
>     } else {
>       os::current_thread_enable_wx(_old_mode);
>     }
>   }
> };
> ```

I honestly don't find this easier than the solution @parttimenerd proposes, using a OS thread local. Using an OS thread local makes this whole system independent from Thread, so you don't need to know about Thread and don't rely on Thread::current being present.

It also would be slightly faster. Using Thread, we'd access TLS to get Thread::current, then dereference that to read the wx state . OTOH using OS TLS, we access TLS to get the wx state directly. We save one dereference.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 07:03:41 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 07:03:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <7MNCDtaPTnKWN2k1DfuEUf8RIcQza2I2Q4IUa7Nm8Qs=.cb1605ee-2fab-4a49-b726-9bcf2b62c76a@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <7MNCDtaPTnKWN2k1DfuEUf8RIcQza2I2Q4IUa7Nm8Qs=.cb1605ee-2fab-4a49-b726-9bcf2b62c76a@github.com>
Message-ID: <J3iTW7IcwD9Ax503NbF_mUIsQ0vfe8ZiincIRUYdhnw=.42832a80-a197-4e79-b44a-3ff361fdfc23@github.com>

On Thu, 10 Mar 2022 05:52:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Why don't we just switch it on once, for a thread that conceivably may call into generated code, and be done with? Why is this fine granular switching even needed? I find it difficult to imagine an attack vector that exploits having this always enabled for a thread. After all, we have to mark code cache with MAP_JIT already, so it is not like we can execute arbitrary memory ranges.

A java thread executes the code (interpreter, JIT) and changes the code (e.g. it could make a nmethod non entrant, change inline cache). Code modifications are done in VM (runtime) call. So WX state is tied to java thread state. The WX management is done more to satisfy the platform requirement, than to make the system more secure.

> Related to that, how much does this call cost? Is this a runtime call into the pthread library or does it get inlined somehow? Because things like SafeFetch are trimmed to be super cheap if the memory can be accessed. Doing a pthread call on every invocation may throw off the cost benefit ratio.

SafeFetch is much more expensive compared the direct memory access. So I assume it's used only when the real chance exists the access may fail, and the average cost of SafeFetch is much higher than the best case. 

Yes, WX management is offered via a pthread function call. I haven't investigated if the native compiler can inline the call. The WX management itself considerably cheap https://github.com/openjdk/jdk/pull/2200#issuecomment-773382787.

> Why and where do we need nesting? This would be so much easier if we could just not care.

We swtich the state to WXWrite at the entry in VM call, but a VM call may do another VM call. E.g. a runtime VM calls the JNI GetLongField. So GetLongField could be called from a code executing in Java (WXExec) and VM (WXWrite) states, the WX state should be restored back on leaving JNI function. The original state is tracked in Thread.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 07:12:40 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 07:12:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <bq7COCxcwcLZ0-wIdVuz2sSrVpdNr4SMAA3t5wrbnEc=.a2fbccbd-e51c-4067-ba47-ef0caf048394@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <bq7COCxcwcLZ0-wIdVuz2sSrVpdNr4SMAA3t5wrbnEc=.a2fbccbd-e51c-4067-ba47-ef0caf048394@github.com>
Message-ID: <m7Z4Wwpu7pOhDIYGuHzyQXD6_nSZkmBREXsXUxW4-2U=.5111868b-252f-4440-896c-720316adab09@github.com>

On Wed, 9 Mar 2022 20:25:02 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> Interesting. But I would nonetheless create an assertion that checks that there is no nesting in the case without a Thread object. I would this using a thread local nesting counter in the ThreadWXEnable class (incremented in the constructor and decremented in the destructor).

Hmm, yes. And the assert would need to check the native thread still don't have a Thread object, i.e. the either Thread or TLS is used for tracking. This looks rather complicated, I agree.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 07:34:40 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 07:34:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
Message-ID: <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>

On Thu, 10 Mar 2022 06:00:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Arguably we should restore, upon leaving the VM, the state that has been present before. Because a native thread may already have modified the wx state and overruling it is just rude. But I offhand don't see a way to do this since we have no way (?) to query the current state.

How in general safe to call SafeFetch on a native thread that has no Thread object? The JVM has not initialized the thread, so there could be no JVM signal handler installed. Or using libjsig is mandatory for this case?

I also don't know a good way to query the WX state.

> It also would be slightly faster. Using Thread, we'd access TLS to get Thread::current, then dereference that to read the wx state . OTOH using OS TLS, we access TLS to get the wx state directly. We save one dereference.

If we compare approaches in general (not only SafeFetch), the Thread is already in hands, so we should to compare a read of the field from a C++ object, and the read of a TLS variable. The former could not be slower than the latter.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 07:42:39 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 07:42:39 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <m7Z4Wwpu7pOhDIYGuHzyQXD6_nSZkmBREXsXUxW4-2U=.5111868b-252f-4440-896c-720316adab09@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <bq7COCxcwcLZ0-wIdVuz2sSrVpdNr4SMAA3t5wrbnEc=.a2fbccbd-e51c-4067-ba47-ef0caf048394@github.com>
 <m7Z4Wwpu7pOhDIYGuHzyQXD6_nSZkmBREXsXUxW4-2U=.5111868b-252f-4440-896c-720316adab09@github.com>
Message-ID: <27NDx3zxCmg_D2R2B3WqrsNRE3UXaO4co3rR5faXLyw=.dea1b127-084c-4bb2-b227-69e3881e6b89@github.com>

On Thu, 10 Mar 2022 07:09:27 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > Interesting. But I would nonetheless create an assertion that checks that there is no nesting in the case without a Thread object. I would this using a thread local nesting counter in the ThreadWXEnable class (incremented in the constructor and decremented in the destructor).
> 
> Hmm, yes. And the assert would need to check the native thread still don't have a Thread object, i.e. the either Thread or TLS is used for tracking. This looks rather complicated, I agree.

Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.

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

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

From dholmes at openjdk.java.net  Thu Mar 10 10:20:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Mar 2022 10:20:42 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
Message-ID: <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>

On Thu, 10 Mar 2022 07:31:47 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> How in general safe to call SafeFetch on a native thread that has no Thread object? The JVM has not initialized the thread, so there could be no JVM signal handler installed. 

@AntonKozlov Signal handlers are per-process not per-thread, so a thread need not be attached to the VM for our signal handlers to get involved - that is why they call `Thread::current_or_null_safe()`.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 12:34:43 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 12:34:43 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
Message-ID: <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>

On Thu, 10 Mar 2022 10:17:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Signal handlers are per-process not per-thread, so a thread need not be attached to the VM for our signal handlers to get involved - that is why they call Thread::current_or_null_safe().

Oh, right, thanks. I was too concentrated on thinking another platforms like windows, that missed the example will work for *nix. 

A general question to the bug. The signal mask is per-thread, and a native thread may block the JVM signal. I think safefetch will fail, if somehow we manage to call it on this thread (without jsig). So I'm not sure the safefetch is really safe on all platforms and in all contexts, that is, it always recovers from the read failure if called on a random thread.

Is there a crash that is fixed by the change? I just spotted it is an enhancement, not a bug. Just trying to understand the problem.

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

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

From stuefe at openjdk.java.net  Thu Mar 10 12:46:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Mar 2022 12:46:49 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

Hi Anton,

thanks a lot for your explanations. You made some things clearer to me. My answers are inline.

> > Why don't we just switch it on once, for a thread that conceivably may call into generated code, and be done with? Why is this fine granular switching even needed? I find it difficult to imagine an attack vector that exploits having this always enabled for a thread. After all, we have to mark code cache with MAP_JIT already, so it is not like we can execute arbitrary memory ranges.
> 
> A java thread executes the code (interpreter, JIT) and changes the code (e.g. it could make a nmethod nonentrant, change inline cache). Code modifications are done in VM (runtime) call. So WX state is tied to the java thread state. The WX management is done more to satisfy the platform requirement than to make the system more secure.

Okay, that was the piece I was missing. I was assuming that we have either executing or modifying threads and that a thread was either one or the other (compiler threads compile, java threads run). You are saying that Java Threads may write too. And CompilerThreads, in the case of SafeFetch at least, may run generated code. So switching has to be done as a stack mark. Have I gotten this right?

> 
> > Related to that, how much does this call cost? Is this a runtime call into the pthread library or does it get inlined somehow? Because things like SafeFetch are trimmed to be super cheap if the memory can be accessed. Doing a pthread call on every invocation may throw off the cost-benefit ratio.
> 
> SafeFetch is much more expensive compared the direct memory access. So I assume it's used only when the real chance exists the access may fail, and the average cost of SafeFetch is much higher than the best case.

Yes, we only do this when necessary, but it is supposed to be reasonably cheap if memory is accessible. Its Load (the safefetch blob) -> unconditional jump to the blob -> load target memory -> jump back. Depending on what the pthread library call does, and if it's a real function call into a library, it would be more expensive than that.

> 
> Yes, WX management is offered via a pthread function call. I haven't investigated if the native compiler can inline the call. The WX management itself considerably cheap [#2200 (comment)](https://github.com/openjdk/jdk/pull/2200#issuecomment-773382787).
> 
> > Why and where do we need nesting? This would be so much easier if we could just not care.
> 
> We swtich the state to WXWrite at the entry in VM call, but a VM call may do another VM call. E.g. a runtime VM calls the JNI GetLongField. So GetLongField could be called from a code executing in Java (WXExec) and VM (WXWrite) states, the WX state should be restored back on leaving JNI function. The original state is tracked in Thread.

Okay, thanks again for clarifying.

> > Arguably we should restore, upon leaving the VM, the state that has been present before. Because a native thread may already have modified the wx state and overruling it is just rude. But I offhand don't see a way to do this since we have no way (?) to query the current state.
> 
> How in general safe to call SafeFetch on a native thread that has no Thread object?

SafeFetch is safe to call if the stub routine exists. So it is safe after VM initialization. And that can be tested too. Callers, when in doubt, are encouraged to use `CanUseSafeFetch` to check if VM is still in pre-initialization time. `CanUseSafeFetch` + `SafeFetch` should never crash, regardless of when and by whom it was called. We also have `os::is_readable_pointer()`, which wraps these two calls for convenience.

> The JVM has not initialized the thread, so there could be no JVM signal handler installed. Or using libjsig is mandatory for this case?

As David wrote, the Signal handler is per process. It is set as part of VM initialization before SafeFetch blob is generated. Foreign threads still enter the signal handler. So crashes in foreign threads still generate hs-err reports. Depending on how your support is organized that's either a bug or a feature :)

> 
> I also don't know a good way to query the WX state.
> 
> > It also would be slightly faster. Using Thread, we'd access TLS to get Thread::current, then dereference that to read the wx state . OTOH using OS TLS, we access TLS to get the wx state directly. We save one dereference.
> 
> If we compare approaches in general (not only SafeFetch), the Thread is already in hands, so we should to compare a read of the field from a C++ object, and the read of a TLS variable. The former could not be slower than the latter.

You lost me here. To me most of the invocations of `ThreadWXEnable` seem to use `Thread::current()`. Only those who retrieve the thread from the JNI environment don't.

IIRC, TLS, at least on Linux, lives at the front of the thread stack, so accessing it should be quite cheap.

I see the performance point of an option to pass in Thread* in case one already has it. I dislike it a bit because it gives the illusion that you could pass in arbitrary threads when in fact you must pass in Thread::current. But an assertion could help clarifying here.

> 
> Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.

But SafeFetch could be used from outside code as well as VM code. In case of the latter, prior state can either be WXWrite or WXExec. It needs to restore the prior state after the call.

---

To summarize the different proposals:

- you propose to use Thread* when available and assume WXWrite as prior state when not. You argue that if there is no Thread::current, we are not a VM thread and we should need no nesting, so a simple switchback to wxwrite should suffice after leaving SafeFetch, right?
- Johannes proposes to use TLS, and just always support nesting, regardless of who calls.

What I like about Johannes proposal is that its simple. It has fewer dependencies on VM infrastructure and we can mostly just hide it in the platform tree.

Cheers, Thomas

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

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

From dholmes at openjdk.java.net  Thu Mar 10 14:12:51 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 10 Mar 2022 14:12:51 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
 <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
Message-ID: <cp-uylm9aQRTNTdbmqGR9jmdE83kH7FZ7psLunwc_Ro=.512549b4-b346-46d1-a8b3-73cdd1be77a2@github.com>

On Thu, 10 Mar 2022 12:31:06 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The signal mask is per-thread, and a native thread may block the JVM signal.

@AntonKozlov the signal from safefetch (if it is not safe) is a SIGSEGV or SIGBUS. If these signals happen to be blocked and we raise the signal synchronously then we are in undefined behaviour territory. So I guess in that sense yes safefetch is not guaranteed to be safe.

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

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

From akozlov at openjdk.java.net  Thu Mar 10 14:12:51 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Mar 2022 14:12:51 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
Message-ID: <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>

On Thu, 10 Mar 2022 12:41:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> You are saying that Java Threads may write too. And CompilerThreads, in the case of SafeFetch at least, may run generated code. So switching has to be done as a stack mark. Have I gotten this right?

Right.

> Depending on what the pthread library call does, and if it's a real function call into a library, it would be more expensive than that.

Yes, unfortunately we need something like this.

> > If we compare approaches in general (not only SafeFetch), the Thread is already in hands, so we should to compare a read of the field from a C++ object, and the read of a TLS variable. The former could not be slower than the latter.
>
> To me most of the invocations of `ThreadWXEnable` seem to use `Thread::current()`. Only those who retrieve the thread from the JNI environment don't.

Right, JNI env is used e.g. in interfaceSupport.hpp where the most VM entries are defined. I found only few instances of ThreadWXEnable to receive Thread::current() as the argument immediately. In the rest, the Thread is there somewhere in the context.

>
> IIRC, TLS, at least on Linux, lives at the front of the thread stack, so accessing it should be quite cheap.
>
> I see the performance point of an option to pass in Thread* in case one already has it. I dislike it a bit because it gives the illusion that you could pass in arbitrary threads when in fact you must pass in Thread::current. But an assertion could help clarifying here.

There is the assert in Thread::enable_wx, where the implementation actually is unable to handle anything except the current threads.

> > Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.
>
> But SafeFetch could be used from outside code as well as VM code. In case of the latter, prior state can either be WXWrite or WXExec. It needs to restore the prior state after the call.

I'm not sure I understand what is the "outside code". The SafeFetch is the private hotspot function, it cannot be linked with non-JVM code, isn't it?


> To summarize the different proposals:
>
> * you propose to use Thread* when available and assume WXWrite as prior state when not. You argue that if there is no Thread::current, we are not a VM thread and we should need no nesting, so a simple switchback to wxwrite should suffice after leaving SafeFetch, right?

So far I like the another approach more, that is, always assume WXWrite and use the Thread only to assert the state. But I did not understand your concern above.

> * Johannes proposes to use TLS, and just always support nesting, regardless of who calls.
>
> What I like about Johannes proposal is that its simple. It has fewer dependencies on VM infrastructure and we can mostly just hide it in the platform tree.

I'm not opposing the refactoring, it has some advantages, but I'd want to separate functional change from the refactoring. This would aid backporting, at least.

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

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

From stuefe at openjdk.java.net  Thu Mar 10 18:07:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Mar 2022 18:07:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
 <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
Message-ID: <2VVnQ4RiNCtAuWXQ_d-vgj-8uejqKTdAWXwxKJUNix4=.6d88041c-2332-452d-9e70-b9429940d1f0@github.com>

On Thu, 10 Mar 2022 12:31:06 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > Signal handlers are per-process not per-thread, so a thread need not be attached to the VM for our signal handlers to get involved - that is why they call Thread::current_or_null_safe().
> 
> Oh, right, thanks. I was too concentrated on thinking another platforms like windows, that missed the example will work for *nix.
> 
> A general question to the bug. The signal mask is per-thread, and a native thread may block the JVM signal. I think safefetch will fail, if somehow we manage to call it on this thread (without jsig). So I'm not sure the safefetch is really safe on all platforms and in all contexts, that is, it always recovers from the read failure if called on a random thread.

To expand on @dholmes-ora answer: blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE - and then triggering said signal is UB. What happens is OS-dependent. I saw processes vanishing, or hang, or core. It makes sense, since what is the kernel supposed to do. It cannot deliver the signal, and deferring it would require returning to the faulting instruction, that would just re-fault. 

For some more details see e.g. https://bugs.openjdk.java.net/browse/JDK-8252533

> 
> Is there a crash that is fixed by the change? I just spotted it is an enhancement, not a bug. Just trying to understand the problem.

Yes, this issue is a breakout from https://bugs.openjdk.java.net/browse/JDK-8282306, where we'd like to use SafeFetch to make stack walking in AsyncGetCallTrace more robust. AGCT is called from the signal handler, and it may run in any number of situations (e.g. in foreign threads, or threads which are in the process of getting dismantled, etc).

Another situation is error handling itself. When writing an hs-err file, we use SafeFetch to do carefully tiptoe around the possibly corrupt VM state. If the original crash happened in a foreign thread, we still want some of these reports to work (e.g. dumping register content or printing stacks). So SafeFetch should be as robust as possible.

> I'm not opposing the refactoring, it has some advantages, but I'd want to separate functional change from the refactoring. This would aid backporting, at least.

I agree that a minimal patch would be good. I feel partly guilty for this expanding discussion. I'm fine with a minimal change, without any refactoring, in whatever form @parttimenerd choses - be it OS thread local or the approach proposed by you, @AntonKozlov.

Cheers Thomas

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

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

From stuefe at openjdk.java.net  Thu Mar 10 18:10:44 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 10 Mar 2022 18:10:44 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
Message-ID: <9abtTyWumeHahJhxZnL_GX3s9_TdDAZ_e8b7OffYfoI=.c3b0b765-d9f4-4db3-bbd0-48c3598c7aa5@github.com>

On Thu, 10 Mar 2022 14:09:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > > Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.
> > 
> > 
> > But SafeFetch could be used from outside code as well as VM code. In case of the latter, prior state can either be WXWrite or WXExec. It needs to restore the prior state after the call.
> 
> I'm not sure I understand what is the "outside code". The SafeFetch is the private hotspot function, it cannot be linked with non-JVM code, isn't it?

Sorry for being imprecise. I meant SafeFetch is triggered from within a signal handler that runs on a foreign thread. E.g. AGCT or error handling.

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

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

From kdnilsen at amazon.com  Fri Mar 11 01:37:00 2022
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Fri, 11 Mar 2022 01:37:00 +0000
Subject: JBS Issue: Mutator threads may fail to evacuate
Message-ID: <AE1B8708-C277-423D-907A-131B06C9683E@amazon.com>

I?ve filed this ticket with a ?Shenandoah Generational? ?label? in its title: https://bugs.openjdk.java.net/browse/JDK-8282997

We?ve had some discussion about this issue with Roman Kennke and currently believe the root cause of this problem is related to the out-of-memory during evacuation protocol in traditional Shenandoah (which is the same protocol we are using in Generational Shenandoah).

We seek guidance from the Shenandoah developer community regarding the best way to tackle this.

Thanks.


From dholmes at openjdk.java.net  Fri Mar 11 04:41:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 11 Mar 2022 04:41:42 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <OecZuYqb3wdGouC9Qb8LMH6eecsTtVSqYg55yAmpwwM=.c9dd27fa-0ea3-48e9-8b81-56e069152166@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

The refactoring is a consequence of the initial TLS change as it pollutes the shared os "namespace" unnecessarily. So I'd want to see this neatly packaged where it belongs please.

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

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

From duke at openjdk.java.net  Fri Mar 11 07:11:41 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 11 Mar 2022 07:11:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
Message-ID: <7g4Pfmc7A2hkvw5kQe7Wgj0EzpwH_OdEHPc-O-IxEVM=.60b394b4-c00b-4c66-b262-6e7eec43289b@github.com>

On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   current_thread_wx -> ThreadWX

I'm also personally in favour of packaging it in the OS specific header.

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

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

From duke at openjdk.java.net  Fri Mar 11 07:52:16 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 11 Mar 2022 07:52:16 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove two unnecessary lines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7727/files
  - new: https://git.openjdk.java.net/jdk/pull/7727/files/f206e6d2..cb1255f5

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

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

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

From aph at openjdk.java.net  Fri Mar 11 09:36:45 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Mar 2022 09:36:45 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
Message-ID: <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>

On Thu, 10 Mar 2022 14:09:24 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > Depending on what the pthread library call does, and if it's a real function call into a library, it would be more expensive than that.
> 
> Yes, unfortunately we need something like this.

But we don't need to speculate. If thread-local variables are cheap on MacOS, and there is no reason why they should be expensive, then we can stop worrying and just use a thread-local variable for WX state. We can measure how long it takes, and we only have to care about one platform, MacOS/AArch64.

We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that?

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

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

From duke at openjdk.java.net  Fri Mar 11 09:53:40 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 11 Mar 2022 09:53:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
Message-ID: <niu2S5Dhs_fiyr8z1xfT76449xUwXNeny2qmYfW4ctw=.9a81733a-9c04-40bd-bf51-cc41962e43b6@github.com>

On Fri, 11 Mar 2022 09:33:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

> But we don't need to speculate. If thread-local variables are cheap on MacOS, and there is no reason why they should be expensive, then we can stop worrying and just use a thread-local variable for WX state. We can measure how long it takes, and we only have to care about one platform, MacOS/AArch64.

According to https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: "these accesses are just a move from a system register plus a load/store at a constant offset."

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

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

From stuefe at openjdk.java.net  Fri Mar 11 10:14:43 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Mar 2022 10:14:43 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
Message-ID: <ZFCofTL4KWXiLiZXGkVcUrd-kox5SsR0hrXuWSnCDWM=.e6beee16-d535-4f73-85a3-8452ed89bbb0@github.com>

On Fri, 11 Mar 2022 09:33:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

> We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that?

Do you mean using inline assembly?

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

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

From aph at openjdk.java.net  Fri Mar 11 10:30:42 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 11 Mar 2022 10:30:42 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

On 3/11/22 10:12, Thomas Stuefe wrote:
>     We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that?
> 
> Do you mean using inline assembly?

I'd use out-of-line assembly, as I do for atomic compare-and-swap
on linux:

https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S

But I guess inline would work.

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

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

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

From stuefe at openjdk.java.net  Fri Mar 11 10:48:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Mar 2022 10:48:49 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
Message-ID: <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>

On Fri, 11 Mar 2022 10:27:25 GMT, Andrew Haley <aph at openjdk.org> wrote:

> On 3/11/22 10:12, Thomas Stuefe wrote: We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that? Do you mean using inline assembly?
> I'd use out-of-line assembly, as I do for atomic compare-and-swap on linux: https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S But I guess inline would work.

Oh, this is neat. It would work on all platforms too, or on all we care to implement it for. And it would nicely solve the initialization window problem since it would work before stub routines are generated. We could throw `CanUseSafeFetch` away.

It seems we already do static assembly on bsd aarch. So there is already a path to follow.

But this could also be done as a follow up enhancement. I still like the OS TLS variable idea.

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

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

From fweimer at openjdk.java.net  Fri Mar 11 12:21:45 2022
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Fri, 11 Mar 2022 12:21:45 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <niu2S5Dhs_fiyr8z1xfT76449xUwXNeny2qmYfW4ctw=.9a81733a-9c04-40bd-bf51-cc41962e43b6@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
 <niu2S5Dhs_fiyr8z1xfT76449xUwXNeny2qmYfW4ctw=.9a81733a-9c04-40bd-bf51-cc41962e43b6@github.com>
Message-ID: <6IzXDSNVNqbNgsVAjHd_u_j61q4T5XzxbNBXp0ECjW0=.cc4cd576-90aa-4567-92c2-a40949720889@github.com>

On Fri, 11 Mar 2022 09:50:22 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> According to https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: "these accesses are just a move from a system register plus a load/store at a constant offset."

Ideally you'd still benchmark that. Some AArch64 implementations have really, really slow moves from the system register used as the thread pointer. Hopefully Apple's implementation isn't in that category.

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

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

From akozlov at openjdk.java.net  Fri Mar 11 16:41:47 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 11 Mar 2022 16:41:47 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <9abtTyWumeHahJhxZnL_GX3s9_TdDAZ_e8b7OffYfoI=.c3b0b765-d9f4-4db3-bbd0-48c3598c7aa5@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <9abtTyWumeHahJhxZnL_GX3s9_TdDAZ_e8b7OffYfoI=.c3b0b765-d9f4-4db3-bbd0-48c3598c7aa5@github.com>
Message-ID: <0-bZMVusZ-zdvrRi4INrZlVWrTvR31RvZgijiX2Ymv4=.f0a9ebd2-fbd0-46c1-aa55-998e641b8e78@github.com>

On Thu, 10 Mar 2022 18:07:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > Is it possible to change SafeFetch only? Switch to WXExec before calling the stub and switch WXWrite back unconditionally? We won't need to provide assert in ThreadWXEnable. But SafeFetch can check the assumption with assert via Thread, if it exists.
> > > 
> > > 
> > > But SafeFetch could be used from outside code as well as VM code. In case of the latter, prior state can either be WXWrite or WXExec. It needs to restore the prior state after the call.
> > 
> > 
> > I'm not sure I understand what is the "outside code". The SafeFetch is the private hotspot function, it cannot be linked with non-JVM code, isn't it?
> 
> Sorry for being imprecise. I meant SafeFetch is triggered from within a signal handler that runs on a foreign thread. E.g. AGCT or error handling.

Then the OS TLS way is not better since when the signal handler and SafeFetch start, the state is unknown and is only assumed to be Write (in initialization of TLS variable).

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

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

From akozlov at openjdk.java.net  Fri Mar 11 16:37:46 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 11 Mar 2022 16:37:46 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <2VVnQ4RiNCtAuWXQ_d-vgj-8uejqKTdAWXwxKJUNix4=.6d88041c-2332-452d-9e70-b9429940d1f0@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
 <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
 <2VVnQ4RiNCtAuWXQ_d-vgj-8uejqKTdAWXwxKJUNix4=.6d88041c-2332-452d-9e70-b9429940d1f0@github.com>
Message-ID: <9Pfhr7V3j4Op4px61CEhpa4jVwueR1wQmjLaS8l8x2g=.6404217f-0556-4f9a-b81b-d8642bb73a13@github.com>

On Thu, 10 Mar 2022 18:04:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE - and then triggering said signal is UB. What happens is OS-dependent. I saw processes vanishing, or hang, or core. It makes sense, since what is the kernel supposed to do. It cannot deliver the signal, and deferring it would require returning to the faulting instruction, that would just re-fault.
> For some more details see e.g. https://bugs.openjdk.java.net/browse/JDK-8252533

This UB looks reasonable. My point is that a native thread would run fine with SIGSEGV blocked. But then JVM decides it can do SafeFetch, and things gets nasty. 

> > Is there a crash that is fixed by the change? I just spotted it is an enhancement, not a bug. Just trying to understand the problem.
> 
> Yes, this issue is a breakout from https://bugs.openjdk.java.net/browse/JDK-8282306, where we'd like to use SafeFetch to make stack walking in AsyncGetCallTrace more robust. AGCT is called from the signal handler, and it may run in any number of situations (e.g. in foreign threads, or threads which are in the process of getting dismantled, etc).

I mean, some way to verify the issue is fixed, e.g. a test that does not fail anymore. 

I see AsyncGetCallTrace to assume the JavaThread very soon, or do I look at the wrong place? https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/forte.cpp#L569

> Another situation is error handling itself. When writing an hs-err file, we use SafeFetch to do carefully tiptoe around the possibly corrupt VM state. If the original crash happened in a foreign thread, we still want some of these reports to work (e.g. dumping register content or printing stacks). So SafeFetch should be as robust as possible.

OK, thanks. I think we also handle recursive segfaults recover after interpretation of the corrupted VM state. Otherwise, implementing the printing functions would be too tedious and hard with SafeFetch alone. But I see it's used in printing register content, at least.

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

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

From akozlov at openjdk.java.net  Fri Mar 11 18:02:47 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 11 Mar 2022 18:02:47 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <CSVcwiXb_aMw18SXvV7HNmjqNHkwm6vKz1gEvl_LWjI=.595beb14-0757-40d1-9c69-222d4e8d4b37@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

I looked on the patch again from the perspective of a pure refactoring. It looks fine except we lost one of the asserts.

src/hotspot/share/runtime/thread.cpp line 278:

> 276:   }
> 277: 
> 278:   MACOS_AARCH64_ONLY(DEBUG_ONLY(os::ThreadWX::init();))

This line meant the WX state is not initialized at this point (as a part of Thread constructor). Since there are a several places where the state is initialized and it was easy to miss one, I would like to preserve some assert that the state is initialized.

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

Changes requested by akozlov (Committer).

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

From stuefe at openjdk.java.net  Fri Mar 11 23:37:41 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Mar 2022 23:37:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <9Pfhr7V3j4Op4px61CEhpa4jVwueR1wQmjLaS8l8x2g=.6404217f-0556-4f9a-b81b-d8642bb73a13@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
 <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
 <2VVnQ4RiNCtAuWXQ_d-vgj-8uejqKTdAWXwxKJUNix4=.6d88041c-2332-452d-9e70-b9429940d1f0@github.com>
 <9Pfhr7V3j4Op4px61CEhpa4jVwueR1wQmjLaS8l8x2g=.6404217f-0556-4f9a-b81b-d8642bb73a13@github.com>
Message-ID: <Q2BGc_EDzAQvZt7J3HJJoN41CGeTuueeFfEDHTk5uio=.e630a037-0c81-49ed-ab11-62e7ee132854@github.com>

On Fri, 11 Mar 2022 16:34:29 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE - and then triggering said signal is UB. What happens is OS-dependent. I saw processes vanishing, or hang, or core. It makes sense, since what is the kernel supposed to do. It cannot deliver the signal, and deferring it would require returning to the faulting instruction, that would just re-fault.
> > For some more details see e.g. https://bugs.openjdk.java.net/browse/JDK-8252533
> 
> This UB looks reasonable. My point is that a native thread would run fine with SIGSEGV blocked. But then JVM decides it can do SafeFetch, and things gets nasty.

Blocking synchronous error signals makes zero sense even for normal programs, since you lose the ability to get cores. For the JVM in particular, it also blocks facilities like polling pages, or dynamically querying CPU abilities. So a JVM would not even start with synchronous error signals blocked.

> 
> > > Is there a crash that is fixed by the change? I just spotted it is an enhancement, not a bug. Just trying to understand the problem.
> > 
> > 
> > Yes, this issue is a breakout from https://bugs.openjdk.java.net/browse/JDK-8282306, where we'd like to use SafeFetch to make stack walking in AsyncGetCallTrace more robust. AGCT is called from the signal handler, and it may run in any number of situations (e.g. in foreign threads, or threads that are in the process of getting dismantled, etc).
> 
> I mean, some way to verify the issue is fixed, e.g. a test that does not fail anymore.

No, tests do not exist. Unfortunately, otherwise this regression would have been detected right away and we would not need this PR.

We have a test though that tests SafeFetch during error handling. That test can be tweaked for this purpose. So, test does not exist yet, but can be easily written. 

> 
> I see AsyncGetCallTrace to assume the JavaThread very soon, or do I look at the wrong place? https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/forte.cpp#L569
> 
> > Another situation is error handling itself. When writing an hs-err file, we use SafeFetch to do carefully tiptoe around the possibly corrupt VM state. If the original crash happened in a foreign thread, we still want some of these reports to work (e.g. dumping register content or printing stacks). So SafeFetch should be as robust as possible.
> 
> OK, thanks. I think we also handle recursive segfaults recover after interpretation of the corrupted VM state. Otherwise, implementing the printing functions would be too tedious and hard with SafeFetch alone. But I see it's used in printing register content, at least.

Secondary error handling is a very coarse-grained tool. If an error reporting step crashes out, we continue with the next step. Has disadvantages though. The total number of retries is very limited. And a faulting error reporting step still hurts, because its report is compromised. E.g. if the call stack printing crashes out, we have no call stack. This is not an abstract problem. Its a very concrete and typical problem.

I spend a large part of my work with hs-err reports. They are of very high importance to us. We (SAP) have invested a lot of time and effort in hardening out OpenJDK error reporting, and SafeFetch is an important part of that. For example, we provided the facility that made SafeFetch usable in signal handling. It would be nice if our work was not compromised. Please let us find a way forward here.

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

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

From stuefe at openjdk.java.net  Fri Mar 11 23:43:47 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Mar 2022 23:43:47 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
 <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
Message-ID: <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>

On Fri, 11 Mar 2022 10:44:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > On 3/11/22 10:12, Thomas Stuefe wrote: We could also redefine SafeFetch on MacOS/AArch64 to not need WX. We could do this by statically generating SafeFetch on that platform, and it wouldn't be in the JIT region at all. Why not just do that? Do you mean using inline assembly?
> > I'd use out-of-line assembly, as I do for atomic compare-and-swap on linux: https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S But I guess inline would work.
> 
> Oh, this is neat. It would work on all platforms too, or on all we care to implement it for. And it would nicely solve the initialization window problem since it would work before stub routines are generated. We could throw `CanUseSafeFetch` away.
> 
> It seems we already do static assembly on bsd aarch. So there is already a path to follow.
> 
> But this could also be done as a follow up enhancement. I still like the OS TLS variable idea.

I spent some time doing a static implementation of SafeFetch on Linux x64, and its not super trivial. The problem is that we need to know addresses of instructions inside that function. I can set labels in assembly, and I can export them, but so far I have been unable to use them as addresses in C++ code. I will research some more.

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

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

From fweimer at openjdk.java.net  Sat Mar 12 07:48:41 2022
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Sat, 12 Mar 2022 07:48:41 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
 <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
 <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>
Message-ID: <ORoyfyhQPqMu456BwPymdVSTpcFPK4lSrPpkoiiHl5g=.dadc0612-0dfb-4ccd-9030-de592ec939e5@github.com>

On Fri, 11 Mar 2022 23:40:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I spent some time doing a static implementation of SafeFetch on Linux x64, and its not super trivial. The problem is that we need to know addresses of instructions inside that function. I can set labels in assembly, and I can export them, but so far I have been unable to use them as addresses in C++ code. I will research some more.

There are basically two ways (easy) to do it. Put global symbols like


        .globl address_of_label
address_of_label:


into the assembler sources and use

```c++
        extern char address_of_label[] __attribute__ ((visibility ("hidden")));


from the C++ side.

Or use a local label, and export the difference to the function start to a local label in a global data symbol from the assembler side:


        .globl SafeFetch // Real function name goes here.
SafeFetch:
        // ?
.Llabel:
        // ?

        .section .rodata
        .globl SafeFetch_label_offset
        .p2align 3
SafeFetch_label_offset:
        .quad .Llabel - SafeFetch
	.type SafeFetch_label_offset, @object
	.size SafeFetch_label_offset, 8


And use

```c++
extern uintptr_t SafeFetch_label_offset __attribute__ ((__visibility ("hidden")));


and the expression `(uintptr_t) &SafeFetch + SafeFetch_label_offset` to compute the final address. The second approach is friendlier to tools (which may get confused by symbols in the middle of functions).

If you have a PR, please Cc: me on it, I will have a look.

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

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

From aph at openjdk.java.net  Sat Mar 12 12:35:43 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 12 Mar 2022 12:35:43 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <ORoyfyhQPqMu456BwPymdVSTpcFPK4lSrPpkoiiHl5g=.dadc0612-0dfb-4ccd-9030-de592ec939e5@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
 <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
 <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>
 <ORoyfyhQPqMu456BwPymdVSTpcFPK4lSrPpkoiiHl5g=.dadc0612-0dfb-4ccd-9030-de592ec939e5@github.com>
Message-ID: <fK8XkkG4p10ovdkHy9cWqD-A3aRSRZzZ6x5A2EDqu0M=.5a726e75-567d-4d9e-8d3d-9c0878d65904@github.com>

On Sat, 12 Mar 2022 07:45:57 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> into the assembler sources and use
> 
> ```c++
>         extern char address_of_label[] __attribute__ ((visibility ("hidden")));

ITYM

extern "C" char address_of_label[] __attribute__ ((visibility ("hidden")));

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

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

From aph at openjdk.java.net  Sat Mar 12 12:35:43 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 12 Mar 2022 12:35:43 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <6IzXDSNVNqbNgsVAjHd_u_j61q4T5XzxbNBXp0ECjW0=.cc4cd576-90aa-4567-92c2-a40949720889@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
 <niu2S5Dhs_fiyr8z1xfT76449xUwXNeny2qmYfW4ctw=.9a81733a-9c04-40bd-bf51-cc41962e43b6@github.com>
 <6IzXDSNVNqbNgsVAjHd_u_j61q4T5XzxbNBXp0ECjW0=.cc4cd576-90aa-4567-92c2-a40949720889@github.com>
Message-ID: <Hv_kXVKECw5Am-6gbabuARHNB3dhnLHGzuu8jUBbSD8=.7206393d-a6d3-4c63-8b33-b98b53b36055@github.com>

On Fri, 11 Mar 2022 12:18:36 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> > According to https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: "these accesses are just a move from a system register plus a load/store at a constant offset."
> 
> Ideally you'd still benchmark that. Some AArch64 implementations have really, really slow moves from the system register used as the thread pointer. Hopefully Apple's implementation isn't in that category.

In a tight loop, loads from __thread variables take 1ns. It's this:


    0x18ea1c530 <+0>:   ldr    x16, [x0, #0x8]
    0x18ea1c534 <+4>:   mrs    x17, TPIDRRO_EL0 
    0x18ea1c538 <+8>:   and    x17, x17, #0xfffffffffffffff8
    0x18ea1c53c <+12>:  ldr    x17, [x17, x16, lsl #3]
    0x18ea1c540 <+16>:  cbz    x17, 0x18ea1c550          ; only executed first time
    0x18ea1c544 <+20>:  ldr    x16, [x0, #0x10]
    0x18ea1c548 <+24>:  add    x0, x17, x16
    0x18ea1c54c <+28>:  ret    


... which looks the same as what glibc does. Not bad, but quite a lot more to do than a simple load.

I'd still use a static SafeFetch, with no W^X fiddling. It just seems to me much more reasonable.

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

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

From fweimer at openjdk.java.net  Sat Mar 12 14:24:45 2022
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Sat, 12 Mar 2022 14:24:45 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <fK8XkkG4p10ovdkHy9cWqD-A3aRSRZzZ6x5A2EDqu0M=.5a726e75-567d-4d9e-8d3d-9c0878d65904@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
 <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
 <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>
 <ORoyfyhQPqMu456BwPymdVSTpcFPK4lSrPpkoiiHl5g=.dadc0612-0dfb-4ccd-9030-de592ec939e5@github.com>
 <fK8XkkG4p10ovdkHy9cWqD-A3aRSRZzZ6x5A2EDqu0M=.5a726e75-567d-4d9e-8d3d-9c0878d65904@github.com>
Message-ID: <9isICa3xUpK6uY93LAI7asBXeXJSYeqimjnlITqFLPg=.27482165-9f82-4781-93f7-1940ff53c9a5@github.com>

On Sat, 12 Mar 2022 12:32:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > into the assembler sources and use
> > ```c++
> >         extern char address_of_label[] __attribute__ ((visibility ("hidden")));
> > ```
> 
> ITYM
> 
> ```
> extern "C" char address_of_label[] __attribute__ ((visibility ("hidden")));

It doesn't hurt, but the Itanium ABI does not mangle such global data symbols, so it's not strictly needed.

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

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

From aph at openjdk.java.net  Sat Mar 12 17:42:43 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 12 Mar 2022 17:42:43 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <9isICa3xUpK6uY93LAI7asBXeXJSYeqimjnlITqFLPg=.27482165-9f82-4781-93f7-1940ff53c9a5@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <VPqAr5CQPBkWpV6lIn_uf1FWmoSoB0udylHE9QyfKt4=.c306004e-b33c-4596-ad1a-59f66173ce95@github.com>
 <TnWcoEkZfffgSEPtFFdXdv_mH0dkp69cEy02B00K0iU=.f2887607-2c7b-458b-a612-4bef98740bae@github.com>
 <huFakBcR36a3PEraDYXLmdx34thWTIa1zPFYu4zoKac=.9f48b2ee-2ac0-497b-a300-f110663019dc@github.com>
 <ORoyfyhQPqMu456BwPymdVSTpcFPK4lSrPpkoiiHl5g=.dadc0612-0dfb-4ccd-9030-de592ec939e5@github.com>
 <fK8XkkG4p10ovdkHy9cWqD-A3aRSRZzZ6x5A2EDqu0M=.5a726e75-567d-4d9e-8d3d-9c0878d65904@github.com>
 <9isICa3xUpK6uY93LAI7asBXeXJSYeqimjnlITqFLPg=.27482165-9f82-4781-93f7-1940ff53c9a5@github.com>
Message-ID: <wkXsziwovKIoFWCYak0TRlrxOS2Zq6Lt1wp7LhCUZtQ=.e76a4dc3-59c9-460c-9360-22f6327a4121@github.com>

On Sat, 12 Mar 2022 14:21:13 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> > ```
> > extern "C" char address_of_label[] __attribute__ ((visibility ("hidden")));
> > ```
> 
> It doesn't hurt, but the Itanium ABI does not mangle such global data symbols, so it's not strictly needed.

That's an interesting point of view. I guess I never thought about it, but I'd always put symbols for an asm file in an `extern "C"` section anyway. But yeah, OK.

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

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

From aph at openjdk.java.net  Sat Mar 12 17:48:46 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 12 Mar 2022 17:48:46 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <Hv_kXVKECw5Am-6gbabuARHNB3dhnLHGzuu8jUBbSD8=.7206393d-a6d3-4c63-8b33-b98b53b36055@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <PpvkFBeUfFZPw9Wc7Uy0d9VNvUToAQfTK3MsURKrJdw=.04187e80-db58-4021-98b5-4e1328abb3e1@github.com>
 <VKwXP-ES39lAizpHMJytJ94_Rxh4-_j3zo-Qsx_hZP8=.b66590f4-b40d-448b-a634-cac17cca09a1@github.com>
 <PFDGcqyfSnff8apuVvMFzBQpdHZnoXE5PoUKKVpuyfI=.b7239454-9607-4e04-81dd-e7301c4ec288@github.com>
 <niu2S5Dhs_fiyr8z1xfT76449xUwXNeny2qmYfW4ctw=.9a81733a-9c04-40bd-bf51-cc41962e43b6@github.com>
 <6IzXDSNVNqbNgsVAjHd_u_j61q4T5XzxbNBXp0ECjW0=.cc4cd576-90aa-4567-92c2-a40949720889@github.com>
 <Hv_kXVKECw5Am-6gbabuARHNB3dhnLHGzuu8jUBbSD8=.7206393d-a6d3-4c63-8b33-b98b53b36055@github.com>
Message-ID: <B0kBuZ62JkX6dqw1nx0RZI5-I_vp86mv03ffwNaDY9I=.6f698a96-9e80-4550-a716-239209cbe024@github.com>

On Sat, 12 Mar 2022 12:30:39 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 1ns

Incidentally, there must be a lot of speculation and bypassing going on there. I can see 15 cycles of latency, probably 20, so that'd be more like 5ns start to finish. M1 is a remarkable thing.

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

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

From stuefe at openjdk.java.net  Mon Mar 14 08:06:46 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Mar 2022 08:06:46 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <xL5Ps2Ix9DFE0Zxw9LtGOMm21gogaQo7zI1oq9Z6N64=.de2b6b2d-abca-45e3-a8bd-e45155bf952b@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

Hi Florian,

> If you have a PR, please Cc: me on it, I will have a look.

Thanks a lot, Florian! I got it to work under Linux x64.

My error was that I had declared the label in C++ as `extern void* SafeFetch_continuation`. Declaring it as `extern char _SafeFetch32_continuation[] __attribute__ ((visibility ("hidden")));` as you suggested does the trick. I'm not sure I understand the difference.

>> extern "C"

> It doesn't hurt, but the Itanium ABI does not mangle such global data symbols, so it's not strictly needed.

I don't understand this remark, what does Itanium have to do with this?

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

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

From fweimer at openjdk.java.net  Mon Mar 14 08:22:53 2022
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Mon, 14 Mar 2022 08:22:53 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <xL5Ps2Ix9DFE0Zxw9LtGOMm21gogaQo7zI1oq9Z6N64=.de2b6b2d-abca-45e3-a8bd-e45155bf952b@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <xL5Ps2Ix9DFE0Zxw9LtGOMm21gogaQo7zI1oq9Z6N64=.de2b6b2d-abca-45e3-a8bd-e45155bf952b@github.com>
Message-ID: <etx16Ip-dVRYQXE_yvyYF_ztZllkPQBb7uN2mjFIFIc=.ccbdf456-2f38-4059-bac0-7a03ec5c4901@github.com>

On Mon, 14 Mar 2022 08:03:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thanks a lot, Florian! I got it to work under Linux x64.

Great!

> My error was that I had declared the label in C++ as `extern void* SafeFetch_continuation`. Declaring it as `extern char _SafeFetch32_continuation[] __attribute__ ((visibility ("hidden")));` as you suggested does the trick. I'm not sure I understand the difference.

Your approach might have worked as well, but you would have to use `&SafeFetch_continuation` on the C++ side. Arrays work directly because of pointer decay. The actual type does not matter because you just want to create a code address from that, so there's no corresponding object (in the C++ standard sense) at the address anyway.

Anyway, from what I've seen, the array is more idiomatic.

> > It doesn't hurt, but the Itanium ABI does not mangle such global data symbols, so it's not strictly needed.
> 
> I don't understand this remark, what does Itanium have to do with this?

The [C++ ABI definition](https://github.com/itanium-cxx-abi/cxx-abi) is probably Itanium's most lasting contribution to computing. I think it's used on most non-Windows systems these days, not just on Linux, and of course on all kinds of CPUs.

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

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

From stuefe at openjdk.java.net  Mon Mar 14 09:03:51 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Mar 2022 09:03:51 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <etx16Ip-dVRYQXE_yvyYF_ztZllkPQBb7uN2mjFIFIc=.ccbdf456-2f38-4059-bac0-7a03ec5c4901@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <xL5Ps2Ix9DFE0Zxw9LtGOMm21gogaQo7zI1oq9Z6N64=.de2b6b2d-abca-45e3-a8bd-e45155bf952b@github.com>
 <etx16Ip-dVRYQXE_yvyYF_ztZllkPQBb7uN2mjFIFIc=.ccbdf456-2f38-4059-bac0-7a03ec5c4901@github.com>
Message-ID: <4dPZaM0fgE5DAE58yLG9Zbicg-QWgN5Ikalkf4vFUE8=.6c45e3cb-c4f5-4e6e-abef-4c950e2cb41f@github.com>

On Mon, 14 Mar 2022 08:19:41 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> > Thanks a lot, Florian! I got it to work under Linux x64.
> 
> Great!
> 
> > My error was that I had declared the label in C++ as `extern void* SafeFetch_continuation`. Declaring it as `extern char _SafeFetch32_continuation[] __attribute__ ((visibility ("hidden")));` as you suggested does the trick. I'm not sure I understand the difference.
> 
> Your approach might have worked as well, but you would have to use `&SafeFetch_continuation` on the C++ side. Arrays work directly because of pointer decay.

Ah, that makes sense. I wondered why the address did not look like a code pointer in C++.

Anyway, got Linux x86_32 working too. Now I am working on aarch64. 

> 
> Anyway, from what I've seen, the array is more idiomatic.
> 
> > > It doesn't hurt, but the Itanium ABI does not mangle such global data symbols, so it's not strictly needed.
> > 
> > 
> > I don't understand this remark, what does Itanium have to do with this?
> 
> The [C++ ABI definition](https://github.com/itanium-cxx-abi/cxx-abi) is probably Itanium's most lasting contribution to computing. I think it's used on most non-Windows systems these days, not just on Linux, and of course on all kinds of CPUs.

Interesting to know. Thanks!

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

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

From duke at openjdk.java.net  Mon Mar 14 10:20:46 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 14 Mar 2022 10:20:46 GMT
Subject: Withdrawn: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
Message-ID: <aRjlFEw9zLgIy43GkIfsyfz2amvvzp1bE11WE-7XgjU=.26c99ec8-34be-49f9-8674-3b98012ddd66@github.com>

On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Mon Mar 14 10:20:46 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Mon, 14 Mar 2022 10:20:46 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <mqNNTg7Syc8854LcUbhCq37ST3pvFnX8-PD2vECIgQk=.57c140c8-77a3-4e17-9c2b-a3f0371211aa@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

We're looking into solutions and create a new PR if necessary.

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

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

From redestad at openjdk.java.net  Mon Mar 14 19:44:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 14 Mar 2022 19:44:47 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v15]
In-Reply-To: <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>
Message-ID: <pFICk7JY3KULcTG4aI6G0wUpleTttDT6KzfGDimkB74=.33af63cd-563a-404e-b8e7-7829ee65e0cb@github.com>

On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year in new test

Gentle reminder that I need a review of the aarch64 changes.

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

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

From rriggs at openjdk.java.net  Mon Mar 14 20:33:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 14 Mar 2022 20:33:41 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v15]
In-Reply-To: <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>
Message-ID: <PFpVX3nXYiODuu28kcUSxK9oG7qxLPPhmkSGPU6KPhY=.ec16b37b-f781-433e-bc1f-1054f1488a8c@github.com>

On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
>> 
>> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
>> 
>> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
>> 
>> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
>> 
>> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright year in new test

core libs String.java changes look fine.

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

Marked as reviewed by rriggs (Reviewer).

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

From redestad at openjdk.java.net  Tue Mar 15 11:02:47 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 15 Mar 2022 11:02:47 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v15]
In-Reply-To: <PFpVX3nXYiODuu28kcUSxK9oG7qxLPPhmkSGPU6KPhY=.ec16b37b-f781-433e-bc1f-1054f1488a8c@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
 <HLfRwgmfezCUFtAdzvhqz2xeLCfBHWE0oECXW8wHo1o=.a3d4d7e0-c5d8-4872-8d77-cf9b242c73a6@github.com>
 <PFpVX3nXYiODuu28kcUSxK9oG7qxLPPhmkSGPU6KPhY=.ec16b37b-f781-433e-bc1f-1054f1488a8c@github.com>
Message-ID: <-T5CXmH7O8EAO-UeX913WJJTZQBdVAms8RNLQx1NJOU=.2befca9f-3850-4f33-93f3-73b89e13b10d@github.com>

On Mon, 14 Mar 2022 20:30:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright year in new test
>
> core libs String.java changes look fine.

Thanks @RogerRiggs 

I intend to push this soon regardless, but would appreciate an explicit review of the aarch64 changes from an aarch64 maintainer.

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

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

From mdoerr at openjdk.java.net  Tue Mar 15 15:10:25 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 15 Mar 2022 15:10:25 GMT
Subject: RFR: Generational ShenandoahGC on PPC64
In-Reply-To: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
References: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
Message-ID: <ztG5grnIXzB7JfPQnXhB57dZdjVjmMi00j4s7ZFSHTk=.21b23856-8f2e-4cf7-a16d-490e76362be2@github.com>

On Tue, 22 Feb 2022 14:32:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 code for Generational ShenandoahGC.

Some benchmarks (jbb2005 and jbb2015) have passed with the recent fixes (also with -XX:+FullGCALot in fast debug build). One bug regarding an invalid state transition is reported, but no problem related to the PPC64 specific code is known. So, I think this PR is ready for

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

PR: https://git.openjdk.java.net/shenandoah/pull/118

From tschatzl at openjdk.java.net  Tue Mar 15 15:26:10 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 15 Mar 2022 15:26:10 GMT
Subject: RFR: 8283186: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
Message-ID: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>

Hi all,

  can I have reviews for this change that explicitly passes a third temp parameter to `MacroAssembler::store_heap_oop` so that `G1BarrierSetAssembler::oop_store_at` (and the equivalent Shenandoah code) does not need to invent some out of thin air? This makes the code much less surprising.

The interesting part of this change is probably the first hunk in `src/hotspot/cpu/x86/templateTable_x86.cpp`, the rest is just passing on that additional parameter.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - initial version

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

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

From eosterlund at openjdk.java.net  Tue Mar 15 15:35:47 2022
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 15 Mar 2022 15:35:47 GMT
Subject: RFR: 8283186: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>
References: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>
Message-ID: <l3BER_p_04kWysylhapaL8QlpenLTa6hHGTDd5mgv2k=.19c3ebcc-cea6-439b-9bd8-f03ea9f5f1e3@github.com>

On Tue, 15 Mar 2022 15:20:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that explicitly passes a third temp parameter to `MacroAssembler::store_heap_oop` so that `G1BarrierSetAssembler::oop_store_at` (and the equivalent Shenandoah code) does not need to invent some out of thin air? This makes the code much less surprising.
> 
> The interesting part of this change is probably the first hunk in `src/hotspot/cpu/x86/templateTable_x86.cpp`, the rest is just passing on that additional parameter.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks awesome.

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

Marked as reviewed by eosterlund (Reviewer).

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

From wkemper at openjdk.java.net  Wed Mar 16 18:18:07 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 16 Mar 2022 18:18:07 GMT
Subject: RFR: Allow old collections to span degenerated young collections
Message-ID: <gAZctRdQ9RPcdtXd8hjCByHtO7KQOYMGkhS8prSajh4=.458dfe37-4e81-4df5-85bb-6b8747fcb99e@github.com>

Prior to this change, a degenerated young cycle would cause an old collection effort to be abandoned. 

Summary of changes:
* Resetting state of old GC during cancellation has been consolidated
* When old marking is in progress, SATB queues are serviced during init mark of concurrent cycles (bug fix)
* Old GC cannot be interrupted between end of final mark and final roots (bug fix)

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

Commit messages:
 - Merge branch 'shenandoah' into young-degen-during-old-mark
 - Revert "Mutator may fail to evacuate"
 - Old generation collection does not use degeneration point
 - Change misleading method name
 - Purge SATB when degenerated cycle begins from outside of concurrent cycle
 - Allow degenerated bootstrap cycles and cancel old gc for concurrent global cycles
 - Only transfer old SATB pointers at start of init mark
 - Only cancel old gc for full GC in generational mode
 - Manage satb buffers at start of degenerated cycle
 - Do not interrupt old GC before clearing weak roots
 - ... and 15 more: https://git.openjdk.java.net/shenandoah/compare/98b21327...0cd5ecdf

Changes: https://git.openjdk.java.net/shenandoah/pull/124/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=124&range=00
  Stats: 194 lines in 16 files changed: 95 ins; 55 del; 44 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/124.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/124/head:pull/124

PR: https://git.openjdk.java.net/shenandoah/pull/124

From kdnilsen at openjdk.java.net  Wed Mar 16 18:47:17 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 16 Mar 2022 18:47:17 GMT
Subject: RFR: Allow old collections to span degenerated young collections
In-Reply-To: <gAZctRdQ9RPcdtXd8hjCByHtO7KQOYMGkhS8prSajh4=.458dfe37-4e81-4df5-85bb-6b8747fcb99e@github.com>
References: <gAZctRdQ9RPcdtXd8hjCByHtO7KQOYMGkhS8prSajh4=.458dfe37-4e81-4df5-85bb-6b8747fcb99e@github.com>
Message-ID: <_YbIiaUg009xTy3iOe30CoyiTS-X5yoLilcb5yC66Qo=.6e0b4027-768a-476c-9fcd-2e91b58c270f@github.com>

On Wed, 16 Mar 2022 18:11:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Prior to this change, a degenerated young cycle would cause an old collection effort to be abandoned. 
> 
> Summary of changes:
> * Resetting state of old GC during cancellation has been consolidated
> * When old marking is in progress, SATB queues are serviced during init mark of concurrent cycles (bug fix)
> * Old GC cannot be interrupted between end of final mark and final roots (bug fix)

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/124

From wkemper at openjdk.java.net  Wed Mar 16 20:40:32 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 16 Mar 2022 20:40:32 GMT
Subject: Integrated: Allow old collections to span degenerated young
 collections
In-Reply-To: <gAZctRdQ9RPcdtXd8hjCByHtO7KQOYMGkhS8prSajh4=.458dfe37-4e81-4df5-85bb-6b8747fcb99e@github.com>
References: <gAZctRdQ9RPcdtXd8hjCByHtO7KQOYMGkhS8prSajh4=.458dfe37-4e81-4df5-85bb-6b8747fcb99e@github.com>
Message-ID: <bxUvAnNoPXt4WP8gWf8sePEGeagZviwuH_uYjss3SDs=.e919dd52-1a4a-49ac-95e4-c7af0a5ac58c@github.com>

On Wed, 16 Mar 2022 18:11:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Prior to this change, a degenerated young cycle would cause an old collection effort to be abandoned. 
> 
> Summary of changes:
> * Resetting state of old GC during cancellation has been consolidated
> * When old marking is in progress, SATB queues are serviced during init mark of concurrent cycles (bug fix)
> * Old GC cannot be interrupted between end of final mark and final roots (bug fix)

This pull request has now been integrated.

Changeset: 958ea3bc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/958ea3bc0b42f6a1df05dab1f10498788ad73d2d
Stats:     194 lines in 16 files changed: 95 ins; 55 del; 44 mod

Allow old collections to span degenerated young collections

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/124

From redestad at openjdk.java.net  Thu Mar 17 09:13:23 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 09:13:23 GMT
Subject: RFR: 8281146: Replace StringCoding.hasNegatives with
 countPositives [v16]
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <1pPTN2fxiRObl90zDb2ObrnuKswJ7Z42TUox2-XDhSY=.e2c705ca-f057-45a0-b687-fc473bd28305@github.com>

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Disallow negative values in TestCountPositives test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7231/files
  - new: https://git.openjdk.java.net/jdk/pull/7231/files/bc5a8c80..6f22e1aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=14-15

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

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

From redestad at openjdk.java.net  Thu Mar 17 09:24:38 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Mar 2022 09:24:38 GMT
Subject: Integrated: 8281146: Replace StringCoding.hasNegatives with
 countPositives
In-Reply-To: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
References: <DzglpI1oYUyB2IYco3SVg1rzyKTUSUbejzLAl_SmCJI=.3ddbe1a8-6827-406e-9588-e1f5f31e21c7@github.com>
Message-ID: <azB2tDCEmhEnQBGSp2sFSfupihXiLF1wh6JzMSjDHng=.5432d003-2f74-4fca-9e5f-8cc4fd38caa2@github.com>

On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input.
> 
> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904
> 
> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups.
> 
> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field.
> 
> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix).

This pull request has now been integrated.

Changeset: beedae11
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/beedae1141b6b650dc4cedf1f038afc1c8b460dd
Stats:     619 lines in 36 files changed: 278 ins; 61 del; 280 mod

8281146: Replace StringCoding.hasNegatives with countPositives

Co-authored-by: Lutz Schmidt <lucy at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: kvn, lucy, rriggs

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

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

From mdoerr at openjdk.java.net  Thu Mar 17 16:35:13 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 17 Mar 2022 16:35:13 GMT
Subject: Integrated: Generational ShenandoahGC on PPC64
In-Reply-To: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
References: <Q1LxSvHL3dcRjdZa-RNhVMTxvtnD6PXGlA9Ft0ou5sk=.de3fb9bf-ed90-4a8c-88be-eb4ce81fc402@github.com>
Message-ID: <co4VTT_fbqFzA2mKnCEPYbu9QLy-z3zDbkOsExcRtqw=.5732c3d8-6dd8-4835-aa98-f08f0b93f135@github.com>

On Tue, 22 Feb 2022 14:32:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 code for Generational ShenandoahGC.

This pull request has now been integrated.

Changeset: 576b7dc8
Author:    Martin Doerr <mdoerr at openjdk.org>
Committer: Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/576b7dc8a134a690701682c052406819eebf81f9
Stats:     99 lines in 3 files changed: 92 ins; 2 del; 5 mod

Generational ShenandoahGC on PPC64

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/118

From david.holmes at oracle.com  Thu Mar 17 23:29:15 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2022 09:29:15 +1000
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v6]
In-Reply-To: <9Pfhr7V3j4Op4px61CEhpa4jVwueR1wQmjLaS8l8x2g=.6404217f-0556-4f9a-b81b-d8642bb73a13@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <DjQJeKb8GQGz-i0ipYlX28aDJhV_CwEwd5znwOO1chg=.cec8a015-7ddb-4412-8e4f-eaf95e71c922@github.com>
 <maXbk7NE1fCaVjLFYgjwiBWscTnEA5etjugh6qf0-XA=.1f4001d7-5e4b-4e2f-8f31-df85b747f97e@github.com>
 <Mh7n4dRO1ftTUodf2k_KpDc9mr8-a1EpYe10tjAVD6s=.73151c3e-8b04-49bf-b8c7-796c788967b5@github.com>
 <WjT4ox-bZuR9MFSgVVGKZd5GnZnuyFPi5QDpOFyNec0=.b34f5518-ff27-4e52-9d91-c7419f9bf1f5@github.com>
 <T0-XLhEypwJdLBwhNl-evUwWQRTKY35URdKuuJcvoy4=.891a43c6-39d8-439e-9d71-d646e6fc4d0c@github.com>
 <KwYLz9a_MwhaM6BBeUYoZHmATTcItAqyPcrH6Mr7QME=.8f5ad6ff-a4a4-4c44-b71c-ac34a25452d1@github.com>
 <2VVnQ4RiNCtAuWXQ_d-vgj-8uejqKTdAWXwxKJUNix4=.6d88041c-2332-452d-9e70-b9429940d1f0@github.com>
 <9Pfhr7V3j4Op4px61CEhpa4jVwueR1wQmjLaS8l8x2g=.6404217f-0556-4f9a-b81b-d8642bb73a13@github.com>
Message-ID: <883a1dec-f805-0873-4e68-718cb4cf1f38@oracle.com>

On 12/03/2022 2:37 am, Anton Kozlov wrote:
> On Thu, 10 Mar 2022 18:04:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>> blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE - and then triggering said signal is UB. What happens is OS-dependent. I saw processes vanishing, or hang, or core. It makes sense, since what is the kernel supposed to do. It cannot deliver the signal, and deferring it would require returning to the faulting instruction, that would just re-fault.
>> For some more details see e.g. https://bugs.openjdk.java.net/browse/JDK-8252533
> 
> This UB looks reasonable. My point is that a native thread would run fine with SIGSEGV blocked. But then JVM decides it can do SafeFetch, and things gets nasty.
> 
>>> Is there a crash that is fixed by the change? I just spotted it is an enhancement, not a bug. Just trying to understand the problem.
>>
>> Yes, this issue is a breakout from https://bugs.openjdk.java.net/browse/JDK-8282306, where we'd like to use SafeFetch to make stack walking in AsyncGetCallTrace more robust. AGCT is called from the signal handler, and it may run in any number of situations (e.g. in foreign threads, or threads which are in the process of getting dismantled, etc).
> 
> I mean, some way to verify the issue is fixed, e.g. a test that does not fail anymore.
> 
> I see AsyncGetCallTrace to assume the JavaThread very soon, or do I look at the wrong place? https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/forte.cpp#L569

It is up to the agent setting things up for AGCT to only actually call 
it for JavaThreads.

David
-----

>> Another situation is error handling itself. When writing an hs-err file, we use SafeFetch to do carefully tiptoe around the possibly corrupt VM state. If the original crash happened in a foreign thread, we still want some of these reports to work (e.g. dumping register content or printing stacks). So SafeFetch should be as robust as possible.
> 
> OK, thanks. I think we also handle recursive segfaults recover after interpretation of the corrupted VM state. Otherwise, implementing the printing functions would be too tedious and hard with SafeFetch alone. But I see it's used in printing register content, at least.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7727

From duke at openjdk.java.net  Fri Mar 18 07:21:36 2022
From: duke at openjdk.java.net (Johannes Bechberger)
Date: Fri, 18 Mar 2022 07:21:36 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <yvkxRQFiyc5eEi9LQZfhvSK9doMVB-kFnrQ2g8Sc2GA=.e19ddb7b-8685-40be-89c8-9e5deeaae50e@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

This is not the point: It comes down to API design. If we use SafeFetch in os::is_first_C_frame (and thereby in frame::link_or_null) and not just in ASGCT, then it depends on when the other methods can be called. These methods are e.g. used whenever an error happens and a hs_err file is generated. We cannot guarantee that a JavaThread is always present there.

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

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

From david.holmes at oracle.com  Sun Mar 20 22:48:00 2022
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 21 Mar 2022 08:48:00 +1000
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <yvkxRQFiyc5eEi9LQZfhvSK9doMVB-kFnrQ2g8Sc2GA=.e19ddb7b-8685-40be-89c8-9e5deeaae50e@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <yvkxRQFiyc5eEi9LQZfhvSK9doMVB-kFnrQ2g8Sc2GA=.e19ddb7b-8685-40be-89c8-9e5deeaae50e@github.com>
Message-ID: <d363dda1-5577-9aa8-a59e-98cdaa526bcf@oracle.com>

On 18/03/2022 5:21 pm, Johannes Bechberger wrote:
> On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:
> 
>>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>>
>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Remove two unnecessary lines
> 
> This is not the point: It comes down to API design. If we use SafeFetch in os::is_first_C_frame (and thereby in frame::link_or_null) and not just in ASGCT, then it depends on when the other methods can be called. These methods are e.g. used whenever an error happens and a hs_err file is generated. We cannot guarantee that a JavaThread is always present there.

My comment was specifically in response to your statement:

 > I see AsyncGetCallTrace to assume the JavaThread very soon

But AGCT is only intended to ever be called on JavaThreads.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7727

From fyang at openjdk.java.net  Mon Mar 21 08:08:10 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Mon, 21 Mar 2022 08:08:10 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port
Message-ID: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>

This PR implements JEP 422: Linux/RISC-V Port [1].
The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.

This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.

[1] https://openjdk.java.net/jeps/422

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

Commit messages:
 - 8276799: Implementation of JEP 422: Linux/RISC-V Port

Changes: https://git.openjdk.java.net/jdk/pull/6294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276799
  Stats: 59153 lines in 188 files changed: 59002 ins; 54 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294

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

From fyang at openjdk.java.net  Mon Mar 21 08:08:11 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Mon, 21 Mar 2022 08:08:11 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <aCptbjJQMgc5lDUYJ5KD-4PJ_NcLH4XX5m-nlbcOYrQ=.1de54306-923c-483d-843a-58fc793773bd@github.com>

On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

Rebased to master

keep alive

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

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

From tschatzl at openjdk.java.net  Mon Mar 21 08:29:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 08:29:34 GMT
Subject: RFR: 8283186: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <l3BER_p_04kWysylhapaL8QlpenLTa6hHGTDd5mgv2k=.19c3ebcc-cea6-439b-9bd8-f03ea9f5f1e3@github.com>
References: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>
 <l3BER_p_04kWysylhapaL8QlpenLTa6hHGTDd5mgv2k=.19c3ebcc-cea6-439b-9bd8-f03ea9f5f1e3@github.com>
Message-ID: <qM1pcoWyY7yZDX3jjR280TCtqPhHT4Yp41D5wOo4tsc=.97db0b2f-9ac0-4e10-b23f-b81062b531d9@github.com>

On Tue, 15 Mar 2022 15:32:41 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that explicitly passes a third temp parameter to `MacroAssembler::store_heap_oop` so that `G1BarrierSetAssembler::oop_store_at` (and the equivalent Shenandoah code) does not need to invent some out of thin air? This makes the code much less surprising.
>> 
>> The interesting part of this change is probably the first hunk in `src/hotspot/cpu/x86/templateTable_x86.cpp`, the rest is just passing on that additional parameter.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Looks awesome.

Thanks @fisk for your review

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

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

From tschatzl at openjdk.java.net  Mon Mar 21 08:29:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 08:29:34 GMT
Subject: Integrated: 8283186: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop
In-Reply-To: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>
References: <F7978jxdg8ePy_JwcyuvCLs947sdrf4Zwz83JV66-oI=.b7d953f5-ce91-4212-9588-183b4724614b@github.com>
Message-ID: <to02g_j502E5qFtgD72zxK-1Nfe9rFULJVa_vEEdRu0=.03559c39-7499-48f6-8c64-92e0c33cce8f@github.com>

On Tue, 15 Mar 2022 15:20:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that explicitly passes a third temp parameter to `MacroAssembler::store_heap_oop` so that `G1BarrierSetAssembler::oop_store_at` (and the equivalent Shenandoah code) does not need to invent some out of thin air? This makes the code much less surprising.
> 
> The interesting part of this change is probably the first hunk in `src/hotspot/cpu/x86/templateTable_x86.cpp`, the rest is just passing on that additional parameter.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: e709cb05
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e709cb05dcf67462f266c1f3dae30976b562676d
Stats:     58 lines in 16 files changed: 2 ins; 2 del; 54 mod

8283186: Explicitly pass a third temp register to MacroAssembler::store_heap_oop

Reviewed-by: eosterlund

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

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

From yude.lyd at alibaba-inc.com  Mon Mar 21 09:20:13 2022
From: yude.lyd at alibaba-inc.com (Yude Lin)
Date: Mon, 21 Mar 2022 17:20:13 +0800
Subject: =?UTF-8?B?TWVyZ2luZyBnYyBzdGF0ZSB0ZXN0cyBmb3IgdHdvIGRlcGVuZGVudCBsb2Fkcw==?=
Message-ID: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>

Copied from 8283243 for visibility:

--------

Shenandoah will merge two gc state tests (from two LRBs) if they satisfy certain control flow constraint (in ShenandoahBarrierC2Support::merge_back_to_back_tests). I think there could be an issue if the two loads the two LRBs guard are dependent.

To reproduce, I ran java -XX:-UseCompressedOops -XX:+UseShenandoahGC -XX:CompileCommand=print,*ThreadLocal.set -jar SPECjvm2008.jar -coe -ict -ikv -i 2 -bt 8 derby

The C2 outcome for ThreadLocal.set has:

..
  0: mov 0x268(%r15),%rsi ; Thread t = Thread.currentThread(); // get oop handle
  1: mov (%rsi),%r12 ; Thread t = Thread.currentThread(); // get oop out of oop handle
  2: mov 0x58(%r12),%rbx ; ThreadLocalMap map = getMap(t);
  3: nopl 0x0(%rax)
  4: testb $0x1,0x20(%r15) ; gc state test is too late here
  5: jne 0x00007f0a3508f6e7
..

There is no barrier between line 1 and line 2. There was a barrier, but it was merged with the barrier for line 2, (the gc state tests are merged) and the merged test is placed at line 4. The problem is line 2 could visit from-space object and get outdated data.

If I comment out the call to ShenandoahBarrierC2Support::merge_back_to_back_tests, the outcome is more like what I expected:

..
  0: mov 0x268(%r15),%rsi
  1: mov (%rsi),%r12
  2: nopw 0x0(%rax,%rax,1)
  3: testb $0x1,0x20(%r15) ; first gc state test
  4: jne 0x00007ff55d077207
  5: mov 0x58(%r12),%rbx
  6: testb $0x1,0x20(%r15) ; second gc state test
  7: jne 0x00007ff55d077235
..

I think the merging didn't consider that the second load could use the result from the first load (in this case, r12). Can anyone confirm if this is an issue?

From rwestrel at redhat.com  Mon Mar 21 12:23:02 2022
From: rwestrel at redhat.com (Roland Westrelin)
Date: Mon, 21 Mar 2022 13:23:02 +0100
Subject: Merging gc state tests for two dependent loads
In-Reply-To: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>
References: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>
Message-ID: <87wngna40p.fsf@redhat.com>


> Shenandoah will merge two gc state tests (from two LRBs) if they satisfy certain control flow constraint (in ShenandoahBarrierC2Support::merge_back_to_back_tests). I think there could be an issue if the two loads the two LRBs guard are dependent.
>
> To reproduce, I ran java -XX:-UseCompressedOops -XX:+UseShenandoahGC -XX:CompileCommand=print,*ThreadLocal.set -jar SPECjvm2008.jar -coe -ict -ikv -i 2 -bt 8 derby
>
> The C2 outcome for ThreadLocal.set has:
>
> ..
>   0: mov 0x268(%r15),%rsi ; Thread t = Thread.currentThread(); // get oop handle
>   1: mov (%rsi),%r12 ; Thread t = Thread.currentThread(); // get oop out of oop handle
>   2: mov 0x58(%r12),%rbx ; ThreadLocalMap map = getMap(t);
>   3: nopl 0x0(%rax)
>   4: testb $0x1,0x20(%r15) ; gc state test is too late here
>   5: jne 0x00007f0a3508f6e7
> ..
>
> There is no barrier between line 1 and line 2. There was a barrier, but it was merged with the barrier for line 2, (the gc state tests are merged) and the merged test is placed at line 4. The problem is line 2 could visit from-space object and get outdated data.

I wonder if what you're seeing is that the loads are hoisted above the
gc state test but the results of the chain of loads is used only after
the gc state test. If that's the case, then AFIU, there's no bug
i.e. it's ok to "speculatively" load from the objects assuming they
haven't moved as long as the resulting value are not used until it's
proven they haven't moved..

Are you observing some sort of failure?

Roland.


From akozlov at openjdk.java.net  Mon Mar 21 12:29:47 2022
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 21 Mar 2022 12:29:47 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current
In-Reply-To: <d363dda1-5577-9aa8-a59e-98cdaa526bcf@oracle.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <d363dda1-5577-9aa8-a59e-98cdaa526bcf@oracle.com>
Message-ID: <UXwVCIgI18JjWGIHVxuILZaRORl6ifkQ_K3vVQNmAdk=.ff794370-5374-4237-a8c6-6fb1bdd4d3e2@github.com>

On Sun, 20 Mar 2022 22:49:49 GMT, David Holmes <david.holmes at oracle.com> wrote:

> My comment was specifically in response to your statement:
> > I see AsyncGetCallTrace to assume the JavaThread very soon
> 
> But AGCT is only intended to ever be called on JavaThreads.

Sorry, it was my question. It looked for me this way as well (and that ACGT will return shortly if called on non-Java thread; AFAICS SafeFetch in not involved), and I wanted to confirm. The AGCT on non-Java thread was declared to be one of the two major reasons for this patch.

I would support this patch to move W^X management out from Thread to OS-specific code, after the problem with the assert "is initialized" is fixed.

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

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

From stuefe at openjdk.java.net  Mon Mar 21 13:21:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Mar 2022 13:21:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
Message-ID: <DF6XGUyCxmpPyc0Px7_v0_xHmV9z35eus0cvR8KT4G0=.f73d8843-f3b7-40a6-bff0-765354c64b35@github.com>

On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger <duke at openjdk.java.net> wrote:

>> The WXMode for the current thread (on MacOS aarch64) is currently stored in the thread class which is unnecessary as the WXMode is bound to the current OS thread, not the current instance of the thread class.
>> This pull request moves the storage of the current WXMode into a thread local global variable in `os` and changes all related code. SafeFetch depended on the existence of a thread object only because of the WXMode. This pull request therefore removes the dependency, making SafeFetch usable in more contexts.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove two unnecessary lines

I'm currently implementing Andrews proposal for a static safefetch (https://github.com/openjdk/jdk/pull/7865, still in draft, but almost done). That will be more generic solution since we don't have to deal with thread wx state at all. That's why we closed this PR.

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

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

From dholmes at openjdk.java.net  Mon Mar 21 13:21:40 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Mar 2022 13:21:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <DF6XGUyCxmpPyc0Px7_v0_xHmV9z35eus0cvR8KT4G0=.f73d8843-f3b7-40a6-bff0-765354c64b35@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <DF6XGUyCxmpPyc0Px7_v0_xHmV9z35eus0cvR8KT4G0=.f73d8843-f3b7-40a6-bff0-765354c64b35@github.com>
Message-ID: <yVSiTgQNAUWDh8vQjdbFc-u93ArI1xCwafoJ6UfgQQo=.7efa6094-e032-4726-bb47-d95cbbddfeaf@github.com>

On Mon, 21 Mar 2022 12:44:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove two unnecessary lines
>
> I'm currently implementing Andrews proposal for a static safefetch (https://github.com/openjdk/jdk/pull/7865, still in draft, but almost done). That will be more generic solution since we don't have to deal with thread wx state at all. That's why we closed this PR.

The conversation here is some what hard to follow. I do see that "foreign threads" was mentioned by @tstuefe  in the context of AGCT but I have to assume he misspoke there (assuming a foreign thread is one not attached to the VM) as AGCT only works for attached JavaThreads. The signal handler that will call AGCT has to be prepared to find any kind of thread in any state, but AGCT should only be called on the right kinds of thread in the right state.

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

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

From stuefe at openjdk.java.net  Mon Mar 21 13:21:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 21 Mar 2022 13:21:40 GMT
Subject: RFR: 8282475: SafeFetch should not rely on existence of
 Thread::current [v7]
In-Reply-To: <DF6XGUyCxmpPyc0Px7_v0_xHmV9z35eus0cvR8KT4G0=.f73d8843-f3b7-40a6-bff0-765354c64b35@github.com>
References: <_veS70i6iCqTIbTDDfwKCS_R-7u6Ri6vgqtqvBfD00k=.071c7a06-74d0-44da-95a6-ceba8a2037aa@github.com>
 <7cc_n9FTme_L52e9GrtEJyUHemM5GH5LdMSRcwgTGws=.bd6bb1c4-ca8b-4fdc-8ce4-7a61ec315ec3@github.com>
 <DF6XGUyCxmpPyc0Px7_v0_xHmV9z35eus0cvR8KT4G0=.f73d8843-f3b7-40a6-bff0-765354c64b35@github.com>
Message-ID: <KaYkAPUJfrV0tj0Zub751-KaPAI1cxRNzDx29MQVrSc=.acb11e06-a4f1-499f-ab2c-f4828a2b615b@github.com>

On Mon, 21 Mar 2022 12:44:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove two unnecessary lines
>
> I'm currently implementing Andrews proposal for a static safefetch (https://github.com/openjdk/jdk/pull/7865, still in draft, but almost done). That will be more generic solution since we don't have to deal with thread wx state at all. That's why we closed this PR.

> The conversation here is some what hard to follow. I do see that "foreign threads" was mentioned by @tstuefe in the context of AGCT but I have to assume he misspoke there (assuming a foreign thread is one not attached to the VM) as AGCT only works for attached JavaThreads. The signal handler that will call AGCT has to be prepared to find any kind of thread in any state, but AGCT should only be called on the right kinds of thread in the right state.

Sure, AGCT can be limited to VM threads - or maybe already is. But tracking non-VM threads could be a valid use case. 

We have downstream in the SapMachine a facility where we track callstacks from malloc sites - independently from NMT or the VM. With the explicit purpose of catching mallocs from non-VM threads too. For collecting the stack trace, we use some VM utilities, SafeFetch among them. That is a very useful facility. I could argue a similar case for the Async Profiler: why should profiling be limited to Java threads? In the end, if it eats performance, it hurts, regardless whether its a java thread or a non-VM-attached thread. Could be a concurrent native thread burning CPU, why would that not be interesting.

Our concern was with SafeFetch, and AGCT is only one example. SafeFetch should be as safe as possible. Error reporting alone is a sufficient reason.

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

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

From ihse at openjdk.java.net  Mon Mar 21 14:43:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 14:43:33 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <x2ogg8nbVJ3_z8DaXZ_-4j-b6gGuTg3Vtusa99pdeSk=.4776f53d-91f1-4d8c-84c3-6379434d90a4@github.com>

On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

Build changes look good. I can't say anything about the rest of the code.

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

Marked as reviewed by ihse (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Mar 21 16:36:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 16:36:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
Message-ID: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>

This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.

[1] - https://openjdk.java.net/jeps/424

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

Commit messages:
 - Fix TestLayouts on 32-bits
 - Update copyright
 - Drop unused imports in Reflection.java
 - Fix writeOversized for booleans
 - Revert changes to scopedMemoryAccess.cpp
 - Add TestUpcallStack to problem list
 - Revert changes to problem list
 - Revert to previous handshake logic
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282191
  Stats: 66428 lines in 364 files changed: 44012 ins; 19911 del; 2505 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Mon Mar 21 16:36:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 16:36:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <kryJ_fSJC-0jqPpsShAthuqgVub9flb4Oa9Z5RdBO_8=.0c380640-2e40-4566-a01f-3e22db201fd3@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Here is a list of the main changes in this iteration.

#### java.lang.foreign

The API is now a **preview** API in `java.lang.foreign`. As such to be able to use the API, users must pass the `--enable-preview` flag accordingly, to `javac` and `java`.

Since the API now lives in `java.base`, we dropped the `MemoryHandles` class and moved all its var handle combinator methods under `MethodHandles`. We have also dropped the `MemorySegment::map` factory and replaced it with a new overload in `FileChannel`, which plays much better with custom file systems.

#### ResourceScope

The `ResourceScope` abstraction has been renamed to `MemorySession`. Aside from the naming difference (which also is reflected in some of the factories associated with `MemorySession`, another difference are that `MemorySession` now implements `SegmentAllocator` and can be used straight away to allocate segments. Finally, the fact that some sessions are not closeable is now reflected in the API (see `MemorySession::isCloseable`), and a method has been added to create a non-closeable *view* of the memory session.

#### Restricted methods

Addressing the feedback we have received during incubation, the mechanism to control access to restricted methods is now more permissive. Users can still use the `--enable-native-access` flag, to get a strict, opt-in behavior, in case they want to control which modules can access restricted methods in the foreign API. But if no flag is specified, access is allowed, with a runtime warning. Supporting this required some changes in `ModuleBootstrap` so that we could record the fact that we have seen an `--enable-native-access` flag (so that all checks in `Reflection.java` becomes constant).

#### Deterministic library loading/unloading

We have enhanced the `SymbolLookup` abstraction to provide a new symbol lookup, called *library lookup*. A library lookup is a symbol lookup built around a specific native library which is loaded/unloaded using dlopen/LoadLibrary. Library lookups are associated with memory sessions, so the library can be unloaded deterministically when the session is closed.

#### Memory layouts

All memory layout constants feature the expected alignment constraints. For instance, `JAVA_CHAR` is 2 byte aligned, `JAVA_INT` is 4 byte aligned, and so on.

#### Removed functionalities

As we moved the API in `java.base` we have dropped a number of API points which did not seem to add much value, based on the feedback received:

* `SequenceLayout`s now always have a bounded size. As a result, `MemoryLayout::byteSize` no longer returns an optional. A zero-length sequence can be used instead;
*  `NativeSymbol` has been dropped. At the end of the day, its role is undistinguishable from that of a memory segment with zero-length, so API (and users) should use zero-length segments instead;
* `MemorySession::keepAlive` - has been removed; in its place we have a simple, high-order method which executes an action (a  `Runnable`) while keeping the session alive (`MemorySession::whileAlive`);
* `MemoryLayout::map` only provides limited capabilities when rewriting layouts (e.g. it can only replace one layout at a time); as such we removed this API, and we might add something better at a later point.

#### Hotspot changes

While the Panama foreign repo contains several Hotspot changes which simplify and regularize the foreign function support, these changes are not included here, as we have discovered some intermittent instability in macosx-aarch64. We might attempt to integrate the hotspot changes at a later date.

Javadoc: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/javadoc/java.base/module-summary.html
Specdiff: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/specdiff_out/overview-summary.html

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

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

From jboes at openjdk.java.net  Mon Mar 21 16:36:45 2022
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 21 Mar 2022 16:36:45 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <1c6iI0BzRJEWKr5IDBEaZfw6CyXoJw1N5G54lDjpGYc=.52e24356-0cf0-4939-8a7f-776800511b51@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600:

> 598:      * @param elementLayout the source element layout. If the byte order associated with the layout is
> 599:      * different from the native order, a byte swap operation will be performed on each array element.
> 600:      * @return a fresh short array copy of this memory segment.

Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods?

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600:

> 598:      * @param elementLayout the source element layout. If the byte order associated with the layout is
> 599:      * different from the native order, a byte swap operation will be performed on each array element.
> 600:      * @return a fresh short array copy of this memory segment.

Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods?

src/java.base/share/classes/java/lang/foreign/package-info.java line 149:

> 147:  * provided:
> 148:  *
> 149:  * {@snippet lang=java :

missing leading space in comment on line 150 and 162

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986:

> 7984:      * <p>
> 7985:      * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values
> 7986:      * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type

... are the return *types* ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986:

> 7984:      * <p>
> 7985:      * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values
> 7986:      * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type

... are the return *types* ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035:

> 8033:      * @param pos the position of the first coordinate to be inserted
> 8034:      * @param values the series of bound coordinates to insert
> 8035:      * @return an adapter var handle which inserts an additional coordinates,

... which inserts additional coordinates, ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035:

> 8033:      * @param pos the position of the first coordinate to be inserted
> 8034:      * @param values the series of bound coordinates to insert
> 8035:      * @return an adapter var handle which inserts an additional coordinates,

... which inserts additional coordinates, ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151:

> 8149:      *
> 8150:      * @param target the var handle to invoke after the dummy coordinates are dropped
> 8151:      * @param pos position of first coordinate to drop (zero for the leftmost)

... of *the* first coordinate to drop ...

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151:

> 8149:      *
> 8150:      * @param target the var handle to invoke after the dummy coordinates are dropped
> 8151:      * @param pos position of first coordinate to drop (zero for the leftmost)

... of *the* first coordinate to drop ...

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

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

From erikj at openjdk.java.net  Mon Mar 21 17:24:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 21 Mar 2022 17:24:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Build changes look ok.

make/modules/java.base/Lib.gmk line 217:

> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \

Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:


LDFLAGS := $(LDFLAGS_JDKLIB), \
LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \


For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.

I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.

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

Marked as reviewed by erikj (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Mar 21 17:40:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 17:40:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
Message-ID: <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>

On Mon, 21 Mar 2022 17:16:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> make/modules/java.base/Lib.gmk line 217:
> 
>> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
>> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
>> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \
> 
> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:
> 
> 
> LDFLAGS := $(LDFLAGS_JDKLIB), \
> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 
> 
> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.
> 
> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.

Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments.

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

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

From wkemper at openjdk.java.net  Mon Mar 21 18:45:22 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 21 Mar 2022 18:45:22 GMT
Subject: RFR: Global mark is not old mark
Message-ID: <Qu3sRxqFXywePtCy_K513tn-jvawTFXEeGSMdOcQ9jA=.e3517271-e10f-411a-96ea-95fb89254a0c@github.com>

Starting a global mark does not need to set old mark as in-progress and just confuses things.

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

Commit messages:
 - Global mark should not manage state of old mark
 - Merge upstream into shenandoah
 - Revert "Mutator may fail to evacuate"

Changes: https://git.openjdk.java.net/shenandoah/pull/125/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=125&range=00
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/125.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/125/head:pull/125

PR: https://git.openjdk.java.net/shenandoah/pull/125

From jvernee at openjdk.java.net  Mon Mar 21 19:29:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 21 Mar 2022 19:29:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

src/java.base/share/classes/java/lang/foreign/CLinker.java line 176:

> 174:      * @param symbol the address of the target function.
> 175:      * @param function the function descriptor of the target function.
> 176:      * @return a new downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

Maybe drop the "new" from this. Since we want to do caching in the future.
Suggestion:

     * @return a downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

src/java.base/share/classes/java/lang/foreign/CLinker.java line 199:

> 197:      *
> 198:      * @param function the function descriptor of the target function.
> 199:      * @return a new downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

Suggestion:

     * @return a downcall method handle. The method handle type is <a href="CLinker.html#downcall-method-handles"><em>inferred</em></a>

src/java.base/share/classes/java/lang/foreign/MemoryAddress.java line 159:

> 157:      * Creates a memory address from the given long value.
> 158:      * @param value the long value representing a raw address.
> 159:      * @return a new memory address instance.

Similar here. A new address is not always returned.
Suggestion:

     * @return a memory address instance.

src/java.base/share/classes/java/lang/foreign/package-info.java line 230:

> 228:  * where {@code M1}, {@code M2}, {@code ... Mn} are module names (for the unnamed module, the special value {@code ALL-UNNAMED}
> 229:  * can be used). If this option is specified, access to restricted methods is only granted to the modules listed by that
> 230:  * option. If this option is not specified, access to restricted method is enabled for all modules, but

Suggestion:

 * option. If this option is not specified, access to restricted methods is enabled for all modules, but

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 53:

> (failed to retrieve contents of file, check the PR for context)
Keeping this static import would seem more readable here, instead of prefixing everything with `AArch64Architecture.`. (especially in the ABI definition below)

src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53:

> (failed to retrieve contents of file, check the PR for context)
Same here, I think keeping the static import for this would make things more readable.

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

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

From kdnilsen at openjdk.java.net  Mon Mar 21 20:19:11 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 21 Mar 2022 20:19:11 GMT
Subject: RFR: Do not abort coalesce and fill during fullgc
Message-ID: <CQGB99lz32YpPmmeqCviPxH_fKMu_ZTQO-UGpdb7Bi4=.dc6b8590-d4a2-406b-b73a-0b2fa0ef49f9@github.com>

We found that the GC cancellation flag that in some cases causes degenerated GC to upgrade to full GC remains set throughout the full GC effort.  In fact, some of the code within full GC checks this flag to determine if it was upgraded from degenerated GC.  We also discovered that when the cancellation flag is set, the coalesce-and-fill effort that is required for pinned regions does not run to completion.  This results in crashes during subsequent remembered set scans.

This fix uses a new service (ShenandoahHeapRegion::oop_fill_and_coalesce_wo_cancel()) to process pinned regions.  This service always runs to completion, ignoring the status of the GC cancellation flag.

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

Commit messages:
 - Fix spelling error in comment
 - Do not clear cancel gc flag at start of full collection
 - Ignore cancellation requests during coalesce and fill of pinned
 - Merge branch 'shenandoah' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into clear_cancel_b4_full
 - Merge upstream into shenandoah
 - Clear cancel at start of FullGC
 - Revert "Mutator may fail to evacuate"

Changes: https://git.openjdk.java.net/shenandoah/pull/126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=126&range=00
  Stats: 46 lines in 3 files changed: 45 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/126/head:pull/126

PR: https://git.openjdk.java.net/shenandoah/pull/126

From kdnilsen at openjdk.java.net  Mon Mar 21 20:24:00 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 21 Mar 2022 20:24:00 GMT
Subject: RFR: Global mark is not old mark
In-Reply-To: <Qu3sRxqFXywePtCy_K513tn-jvawTFXEeGSMdOcQ9jA=.e3517271-e10f-411a-96ea-95fb89254a0c@github.com>
References: <Qu3sRxqFXywePtCy_K513tn-jvawTFXEeGSMdOcQ9jA=.e3517271-e10f-411a-96ea-95fb89254a0c@github.com>
Message-ID: <6QNTc9QLAeK_prbdO5ZnTM5gN92hhR2wdQCDEFloOT0=.a7dab916-c149-4c37-b429-a609f2659c52@github.com>

On Mon, 21 Mar 2022 18:38:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Starting a global mark does not need to set old mark as in-progress and just confuses things.

Marked as reviewed by kdnilsen (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/125

From wkemper at openjdk.java.net  Mon Mar 21 20:31:06 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 21 Mar 2022 20:31:06 GMT
Subject: RFR: Do not abort coalesce and fill during fullgc
In-Reply-To: <CQGB99lz32YpPmmeqCviPxH_fKMu_ZTQO-UGpdb7Bi4=.dc6b8590-d4a2-406b-b73a-0b2fa0ef49f9@github.com>
References: <CQGB99lz32YpPmmeqCviPxH_fKMu_ZTQO-UGpdb7Bi4=.dc6b8590-d4a2-406b-b73a-0b2fa0ef49f9@github.com>
Message-ID: <Y20umzxbc3uHdF_TOf1seoALhzp3jsWoZJqcL4B21vk=.ce701214-9eca-4db5-954e-938712f3b114@github.com>

On Mon, 21 Mar 2022 20:12:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We found that the GC cancellation flag that in some cases causes degenerated GC to upgrade to full GC remains set throughout the full GC effort.  In fact, some of the code within full GC checks this flag to determine if it was upgraded from degenerated GC.  We also discovered that when the cancellation flag is set, the coalesce-and-fill effort that is required for pinned regions does not run to completion.  This results in crashes during subsequent remembered set scans.
> 
> This fix uses a new service (ShenandoahHeapRegion::oop_fill_and_coalesce_wo_cancel()) to process pinned regions.  This service always runs to completion, ignoring the status of the GC cancellation flag.

Marked as reviewed by wkemper (Committer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/126

From kdnilsen at openjdk.java.net  Mon Mar 21 20:35:11 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 21 Mar 2022 20:35:11 GMT
Subject: Integrated: Do not abort coalesce and fill during fullgc
In-Reply-To: <CQGB99lz32YpPmmeqCviPxH_fKMu_ZTQO-UGpdb7Bi4=.dc6b8590-d4a2-406b-b73a-0b2fa0ef49f9@github.com>
References: <CQGB99lz32YpPmmeqCviPxH_fKMu_ZTQO-UGpdb7Bi4=.dc6b8590-d4a2-406b-b73a-0b2fa0ef49f9@github.com>
Message-ID: <umN8CAhdozlx8kt0cjDIupdu-AfpTTkOJpjnVh-PQv8=.67e50cac-ac18-404d-9b99-65eaf83ce793@github.com>

On Mon, 21 Mar 2022 20:12:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We found that the GC cancellation flag that in some cases causes degenerated GC to upgrade to full GC remains set throughout the full GC effort.  In fact, some of the code within full GC checks this flag to determine if it was upgraded from degenerated GC.  We also discovered that when the cancellation flag is set, the coalesce-and-fill effort that is required for pinned regions does not run to completion.  This results in crashes during subsequent remembered set scans.
> 
> This fix uses a new service (ShenandoahHeapRegion::oop_fill_and_coalesce_wo_cancel()) to process pinned regions.  This service always runs to completion, ignoring the status of the GC cancellation flag.

This pull request has now been integrated.

Changeset: 71fe3e54
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/71fe3e547c9da1ca695fb405f7b2b034548f41cc
Stats:     46 lines in 3 files changed: 45 ins; 0 del; 1 mod

Do not abort coalesce and fill during fullgc

Reviewed-by: wkemper

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

PR: https://git.openjdk.java.net/shenandoah/pull/126

From wkemper at openjdk.java.net  Mon Mar 21 20:49:05 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 21 Mar 2022 20:49:05 GMT
Subject: Integrated: Global mark is not old mark
In-Reply-To: <Qu3sRxqFXywePtCy_K513tn-jvawTFXEeGSMdOcQ9jA=.e3517271-e10f-411a-96ea-95fb89254a0c@github.com>
References: <Qu3sRxqFXywePtCy_K513tn-jvawTFXEeGSMdOcQ9jA=.e3517271-e10f-411a-96ea-95fb89254a0c@github.com>
Message-ID: <c0665RXU8J-WFxNVaERfXX3mjRWln6nd8g56YUNqu2k=.714d5a47-8a5c-487e-aa42-4e3d19d2a812@github.com>

On Mon, 21 Mar 2022 18:38:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Starting a global mark does not need to set old mark as in-progress and just confuses things.

This pull request has now been integrated.

Changeset: ca6fa69e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/ca6fa69e238c747d1f83514d52aeb39d923bce51
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

Global mark is not old mark

Reviewed-by: kdnilsen

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

PR: https://git.openjdk.java.net/shenandoah/pull/125

From mcimadamore at openjdk.java.net  Mon Mar 21 21:25:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 21:25:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <wGG7_ExHc55ht1LxABCOqJgSMyiDucJoE6EvyUAe08w=.683599a8-b916-427b-84c9-783212787c1b@github.com>
Message-ID: <P1SAqwazgRHacbsYjBP6oTIvz2eoFZcP5LrfZZBs3ik=.d6efdfe6-4010-48f9-b49c-8ec1ec9cfd20@github.com>

On Mon, 21 Mar 2022 14:17:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Same here, I think keeping the static import for this would make things more readable.

Good catch. I think the IDE did that when I moved files across; I've fixed few of these, but there's more it seems.

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

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

From fyang at openjdk.java.net  Tue Mar 22 03:31:16 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 22 Mar 2022 03:31:16 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

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

 - Merge remote-tracking branch 'upstream/master' into JDK-8276799
 - 8276799: Implementation of JEP 422: Linux/RISC-V Port

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6294/files
  - new: https://git.openjdk.java.net/jdk/pull/6294/files/33402035..a144cd20

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

  Stats: 2517 lines in 698 files changed: 1371 ins; 865 del; 281 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294

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

From yude.lyd at alibaba-inc.com  Tue Mar 22 03:33:58 2022
From: yude.lyd at alibaba-inc.com (Yude Lin)
Date: Tue, 22 Mar 2022 11:33:58 +0800
Subject: =?UTF-8?B?UmU6IE1lcmdpbmcgZ2Mgc3RhdGUgdGVzdHMgZm9yIHR3byBkZXBlbmRlbnQgbG9hZHM=?=
In-Reply-To: <87wngna40p.fsf@redhat.com>
References: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>,
 <87wngna40p.fsf@redhat.com>
Message-ID: <02300552-2001-4915-9165-5bee5eacd45d.yude.lyd@alibaba-inc.com>


> Are you observing some sort of failure?

No. In this case I haven't observed a failure. It only triggers a fault in a protection mechanism (which should be changed depending on if this really is a bug).

> I wonder if what you're seeing is that the loads are hoisted above the
> gc state test but the results of the chain of loads is used only after
> the gc state test. If that's the case, then AFIU, there's no bug
> i.e. it's ok to "speculatively" load from the objects assuming they
> haven't moved as long as the resulting value are not used until it's
> proven they haven't moved..

The chain of loads result is used after the gc state tests.
But still this changed what I thought was the invariant that lrb guarantees.
Let me use an example to show what might be the problem.

Thread1:                                                           Thread2:
 inside a lock {
                                                                            objB_ts.refC = NULL; // Suppose objB_ts is the to-space reference of objB
                                                                            cond = true; // cond was initialized to false
                                                                          }
inside a lock {
  if (cond == true) {
 objB = objA.refB;
 objC = objB.refC; // expects objC == NULL, but if objB is the from-space reference, then not necessarily NULL
    // gc state tests come after
    // objC will be corrected to point to to-space object, but we expects NULL
  }
}

So if another thread (Thread2) somehow got a to-space reference of objB and made some update.
Thread1 should see this update. Instead if we let thread1 loads from the from-space objB, the
update will be lost. The lrb cannot restore the update. I cannot think of a simpler example but I think
this behaviour breaks many assumptions and could cause other problems?

Yude
------------------------------------------------------------------
From:Roland Westrelin <rwestrel at redhat.com>
Send Time:2022?3?21?(???) 20:23
To:???(??) <yude.lyd at alibaba-inc.com>; shenandoah-dev <shenandoah-dev at openjdk.java.net>
Subject:Re: Merging gc state tests for two dependent loads


> Shenandoah will merge two gc state tests (from two LRBs) if they satisfy certain control flow constraint (in ShenandoahBarrierC2Support::merge_back_to_back_tests). I think there could be an issue if the two loads the two LRBs guard are dependent.
>
> To reproduce, I ran java -XX:-UseCompressedOops -XX:+UseShenandoahGC -XX:CompileCommand=print,*ThreadLocal.set -jar SPECjvm2008.jar -coe -ict -ikv -i 2 -bt 8 derby
>
> The C2 outcome for ThreadLocal.set has:
>
> ..
>   0: mov 0x268(%r15),%rsi ; Thread t = Thread.currentThread(); // get oop handle
>   1: mov (%rsi),%r12 ; Thread t = Thread.currentThread(); // get oop out of oop handle
>   2: mov 0x58(%r12),%rbx ; ThreadLocalMap map = getMap(t);
>   3: nopl 0x0(%rax)
>   4: testb $0x1,0x20(%r15) ; gc state test is too late here
>   5: jne 0x00007f0a3508f6e7
> ..
>
> There is no barrier between line 1 and line 2. There was a barrier, but it was merged with the barrier for line 2, (the gc state tests are merged) and the merged test is placed at line 4. The problem is line 2 could visit from-space object and get outdated data.

I wonder if what you're seeing is that the loads are hoisted above the
gc state test but the results of the chain of loads is used only after
the gc state test. If that's the case, then AFIU, there's no bug
i.e. it's ok to "speculatively" load from the objects assuming they
haven't moved as long as the resulting value are not used until it's
proven they haven't moved..

Are you observing some sort of failure?

Roland.

From dholmes at openjdk.java.net  Tue Mar 22 05:15:35 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Mar 2022 05:15:35 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
Message-ID: <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>

On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port

Hi,

I've looked at everything that is not a RISC-V specific file, except for the C1 changes as the compiler folk will need to approve those.

Some copyrights will need updating to 2022 on the Oracle copyright line please.

I have flagged one issue in regard to C++ atomics - see below.

Thanks,
David

make/autoconf/libraries.m4 line 152:

> 150:   fi
> 151: 
> 152:   # Programs which use C11 or C++11 atomics, like #include <atomic>,

Use of C++ atomics is not allowed in hotspot code base. See the style guide:
https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md

That said, I don't see any actual use of C++ atomics. ??

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

Marked as reviewed by dholmes (Reviewer).

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

From mcimadamore at openjdk.java.net  Tue Mar 22 10:11:47 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 10:11:47 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v2]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <KNk_5Hl0-npZKQkVMXB3cIvod6m9Q-iqdix-W15KTlE=.5dd42f08-240c-41bd-85c6-0879e455c2fc@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments
  * Use `new` instead of `fresh`
  * Drop use of `new` where caching might be used
  * Remove unused imports
  * Add static imports to make code more succint
  * Fix other typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/8e6017dc..6bb1b5c9

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

  Stats: 83 lines in 10 files changed: 2 ins; 7 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From fyang at openjdk.java.net  Tue Mar 22 11:50:13 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 22 Mar 2022 11:50:13 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6294/files
  - new: https://git.openjdk.java.net/jdk/pull/6294/files/a144cd20..b7a31729

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

  Stats: 44 lines in 41 files changed: 0 ins; 1 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294

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

From fyang at openjdk.java.net  Tue Mar 22 11:50:17 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 22 Mar 2022 11:50:17 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
Message-ID: <AAR72egGPI24sF_DykJ3b6KtjK79yoNJz65MabFtqfA=.5b267c1d-c165-4579-a3d2-59894d114019@github.com>

On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang 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 two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port

> Build changes look good. I can't say anything about the rest of the code.
> 
> /reviewers 3

Thanks again for looking at the build changes :-)

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

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

From fyang at openjdk.java.net  Tue Mar 22 11:53:34 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 22 Mar 2022 11:53:34 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
 <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>
Message-ID: <v6FdKk92nob3pvCxz0fBV3YCWvLAzMdHsJPkJ1e6xEo=.d10d619d-316b-480e-8975-910bd19f7991@github.com>

On Tue, 22 Mar 2022 05:12:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi,
> 
> I've looked at everything that is not a RISC-V specific file, except for the C1 changes as the compiler folk will need to approve those.
> 
> Some copyrights will need updating to 2022 on the Oracle copyright line please.

Hi David,
  I have pushed one more commit updating the Oralce copyright line for existing files touched.
  Thanks for looking at this.

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

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

From fyang at openjdk.java.net  Tue Mar 22 12:11:36 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 22 Mar 2022 12:11:36 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
 <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>
Message-ID: <HU1SlU-NS2EFtlHCLJTwg_k5lSSojtZ_meUP7JX_k_0=.827188a4-8044-4a40-ad1e-851682f6f1e8@github.com>

On Tue, 22 Mar 2022 04:13:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fei Yang 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 two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8276799
>>  - 8276799: Implementation of JEP 422: Linux/RISC-V Port
>
> make/autoconf/libraries.m4 line 152:
> 
>> 150:   fi
>> 151: 
>> 152:   # Programs which use C11 or C++11 atomics, like #include <atomic>,
> 
> Use of C++ atomics is not allowed in hotspot code base. See the style guide:
> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md
> 
> That said, I don't see any actual use of C++ atomics. ??

I think the old code comment here is a bit too general. It does not mean we introduce any use of C++ atomics here.
The fact is that RISC-V only has word-sized atomics, it requries libatomic where other common architectures do not [1].
So atomic support would require explicit linking against -latomic on RISC-V. Otherwise we got build errors like:

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

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

From dholmes at openjdk.java.net  Tue Mar 22 12:58:32 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Mar 2022 12:58:32 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
Message-ID: <zH2aiA342BE7HZ_5GkQYNFOaVuIeS7OGLQJsMiadVUk=.90b5514a-b8f5-422d-b8cd-af104e908ab7@github.com>

On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by dholmes (Reviewer).

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

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

From dholmes at openjdk.java.net  Tue Mar 22 12:58:32 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 22 Mar 2022 12:58:32 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]
In-Reply-To: <HU1SlU-NS2EFtlHCLJTwg_k5lSSojtZ_meUP7JX_k_0=.827188a4-8044-4a40-ad1e-851682f6f1e8@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <eTc9Ib4SgZ07Quz849XR6ECDSD5Xv0vjPzvAI8P08S0=.dfd74b96-0cef-4c19-a88c-ed173fe36e61@github.com>
 <muUrdZ-Y2dH__IhwWLfAYZ26y9R5O28KRQwOCuexBP0=.1f96d21b-0d87-46dc-8031-5ce34ab67435@github.com>
 <HU1SlU-NS2EFtlHCLJTwg_k5lSSojtZ_meUP7JX_k_0=.827188a4-8044-4a40-ad1e-851682f6f1e8@github.com>
Message-ID: <gckwW0s2kOjbYsLIyfn3LmE8Nc1xXtmcISvbRzDryNQ=.dc3e31b0-bc5f-459a-8816-65a9d1be0940@github.com>

On Tue, 22 Mar 2022 12:08:01 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> make/autoconf/libraries.m4 line 152:
>> 
>>> 150:   fi
>>> 151: 
>>> 152:   # Programs which use C11 or C++11 atomics, like #include <atomic>,
>> 
>> Use of C++ atomics is not allowed in hotspot code base. See the style guide:
>> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md
>> 
>> That said, I don't see any actual use of C++ atomics. ??
>
> I think the old code comment here is a bit too general. It does not mean we introduce any use of C++ atomics here.
> The fact is that RISC-V only has word-sized atomics, it requries libatomic where other common architectures do not [1].
> So atomic support would require explicit linking against -latomic on RISC-V. Otherwise we got build errors like:

New comment looks good - thanks for clarifying.

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

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

From mcimadamore at openjdk.java.net  Tue Mar 22 14:04:07 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 14:04:07 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - rename syslookup lib on Windows
 - Add missing LIBS flag
 - Simplify syslookup build changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6bb1b5c9..4b2760d3

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

  Stats: 28 lines in 3 files changed: 1 ins; 23 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Tue Mar 22 14:04:10 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 14:04:10 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <L8zdEPAzRKktWFOcpeEhGcxIoFa5iUxZ9GA4Zp-qHEs=.0e9a6021-df8a-4ed9-8cec-8b9732c84f67@github.com>
 <HAMxnSS05k2YSLK8v7yX63AkjJQ2NxoI_X1N7HAac84=.416e196d-2f82-475f-a6bc-e70a68b6672a@github.com>
Message-ID: <DYTB_0p8zXdcTCKtoDmMtAjMs_ZXRwutO0uM7HiuHMM=.858b1ebe-8175-4a38-a7b2-94172e178277@github.com>

On Mon, 21 Mar 2022 17:36:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 217:
>> 
>>> 215:       CXXFLAGS := $(CXXFLAGS_JDKLIB), \
>>> 216:       LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \
>>> 217:       LIBS := $(LIBCXX) -lc -lm -ldl, \
>> 
>> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this:
>> 
>> 
>> LDFLAGS := $(LDFLAGS_JDKLIB), \
>> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
>> 
>> 
>> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build.
>> 
>> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time.
>
> Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments.

I've fixed the makefile as you suggested - I agree the result is much simpler. I've tested the changes on mac/linux/win and everything looks good.

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

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

From rriggs at openjdk.java.net  Tue Mar 22 14:04:34 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Mar 2022 14:04:34 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
Message-ID: <LEZi6_VupCPC_pS7loxYMhu0qREIN1maDO9dPbrFVOg=.e92764d2-66bc-434f-8c74-5341c72b7851@github.com>

On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

The test/jdk files look ok. (I didn't look at the rest)

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

Marked as reviewed by rriggs (Reviewer).

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

From erikj at openjdk.java.net  Tue Mar 22 16:58:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Mar 2022 16:58:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v3]
In-Reply-To: <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UFcCDGmGctywrvTPliyg8WAi2bPIoPITm9BvDUXUF-4=.fa475bef-2d39-4407-9117-8a66c21673e3@github.com>
Message-ID: <qt6-Gdr9219leCluYNBRH9vil85lRVByDFiSukY6j2w=.82fceeec-10a3-4bb1-a6a6-f8e79e62546d@github.com>

On Tue, 22 Mar 2022 14:04:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - rename syslookup lib on Windows
>  - Add missing LIBS flag
>  - Simplify syslookup build changes

make/modules/java.base/Lib.gmk line 217:

> 215:       LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 216:       LIBS := $(LIBCXX), \
> 217:       LIBS_linux := -lc -lm -ldl, \

This looks much better, thanks! Now if you could just fix the indentation of the parameters to 4 spaces, it would be perfect.

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

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

From kvn at openjdk.java.net  Tue Mar 22 17:07:38 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Mar 2022 17:07:38 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
Message-ID: <m67dm93zg_Y6qpSAMyeOZkgdN5RkkZ6typGbvI8ovME=.bb16174e-0692-42d0-953f-3d91abe5f88f@github.com>

On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I looked on C1/C2 changes and compiler tests. Seems reasonable.
But before approval I would need to run changes through our testing.

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

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

From kvn at openjdk.java.net  Tue Mar 22 17:37:36 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Mar 2022 17:37:36 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
Message-ID: <rlZ109KWaWypgc6jGakTKcyyMzMp9d49dHml12Ap-Xk=.dc43e4d5-1e68-415e-92d0-b3896ed05157@github.com>

On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18:

> 16:  *
> 17:  * You should have received a copy of the GNU General Public License version
> 18:  * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

These 2 lines merged into 1 accidentally  causing failure in copyright headers verification.

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

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

From mcimadamore at openjdk.java.net  Tue Mar 22 19:07:12 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Mar 2022 19:07:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v4]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation in Lib.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/4b2760d3..7ec71f73

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

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

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

From erikj at openjdk.java.net  Tue Mar 22 20:46:31 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 22 Mar 2022 20:46:31 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v4]
In-Reply-To: <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UuTDMAAnrUzF27WaoqLM6y5gSA_F_NT_F1bTuamncQs=.eaa56a82-b6ed-429a-bf8f-42399c2b437f@github.com>
Message-ID: <bQ9O-zsr_QE-KUCAfi5-5uah49CJmiX3UhJTdXjePyE=.2df45bf9-e268-43b3-ae46-d157939ab231@github.com>

On Tue, 22 Mar 2022 19:07:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation in Lib.gmk

Marked as reviewed by erikj (Reviewer).

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

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

From fyang at openjdk.java.net  Wed Mar 23 02:03:26 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 23 Mar 2022 02:03:26 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4]
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6294/files
  - new: https://git.openjdk.java.net/jdk/pull/6294/files/b7a31729..d8bef7fa

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

  Stats: 28 lines in 13 files changed: 14 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294

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

From fyang at openjdk.java.net  Wed Mar 23 02:03:27 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 23 Mar 2022 02:03:27 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <LEZi6_VupCPC_pS7loxYMhu0qREIN1maDO9dPbrFVOg=.e92764d2-66bc-434f-8c74-5341c72b7851@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
 <LEZi6_VupCPC_pS7loxYMhu0qREIN1maDO9dPbrFVOg=.e92764d2-66bc-434f-8c74-5341c72b7851@github.com>
Message-ID: <a7j16glOgHEEK19VZeTjKkXfGLp8GUqnWKVg1M1C0AE=.bf9bb26f-440e-4ae8-ae81-d30b52652553@github.com>

On Tue, 22 Mar 2022 14:01:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test/jdk files look ok. (I didn't look at the rest)

Thank you for looking at that part.

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

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

From fyang at openjdk.java.net  Wed Mar 23 02:03:27 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 23 Mar 2022 02:03:27 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <rlZ109KWaWypgc6jGakTKcyyMzMp9d49dHml12Ap-Xk=.dc43e4d5-1e68-415e-92d0-b3896ed05157@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
 <rlZ109KWaWypgc6jGakTKcyyMzMp9d49dHml12Ap-Xk=.dc43e4d5-1e68-415e-92d0-b3896ed05157@github.com>
Message-ID: <HdWzClrPnNyeQNQzZJXK8oPmTqKFBphytI5SzDHPsGQ=.9d3fae2c-cf70-4f3e-b1d4-1ae703725793@github.com>

On Tue, 22 Mar 2022 17:34:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18:
> 
>> 16:  *
>> 17:  * You should have received a copy of the GNU General Public License version
>> 18:  * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> 
> These 2 lines merged into 1 accidentally  causing failure in copyright headers verification.

> I looked on C1/C2 changes and compiler tests. Seems reasonable. But before approval I would need to run changes through our testing.

That's great to hear :-) Thanks for the efforts.

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

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

From fyang at openjdk.java.net  Wed Mar 23 02:03:28 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 23 Mar 2022 02:03:28 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3]
In-Reply-To: <HdWzClrPnNyeQNQzZJXK8oPmTqKFBphytI5SzDHPsGQ=.9d3fae2c-cf70-4f3e-b1d4-1ae703725793@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com>
 <rlZ109KWaWypgc6jGakTKcyyMzMp9d49dHml12Ap-Xk=.dc43e4d5-1e68-415e-92d0-b3896ed05157@github.com>
 <HdWzClrPnNyeQNQzZJXK8oPmTqKFBphytI5SzDHPsGQ=.9d3fae2c-cf70-4f3e-b1d4-1ae703725793@github.com>
Message-ID: <3ImDU5mN1i84E9dzISTXAcGY6JrlzjHUjP7iTaaDgoo=.e1500563-8449-42ac-aa38-964f2995bc3d@github.com>

On Wed, 23 Mar 2022 01:57:25 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18:
>> 
>>> 16:  *
>>> 17:  * You should have received a copy of the GNU General Public License version
>>> 18:  * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>> 
>> These 2 lines merged into 1 accidentally  causing failure in copyright headers verification.
>
>> I looked on C1/C2 changes and compiler tests. Seems reasonable. But before approval I would need to run changes through our testing.
> 
> That's great to hear :-) Thanks for the efforts.

I have fixed the copyright headers verification problem. Please take another look.

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

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

From kvn at openjdk.java.net  Wed Mar 23 02:20:28 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Mar 2022 02:20:28 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4]
In-Reply-To: <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>
Message-ID: <q-UVp-aGUKl2f80QbmVJcfYcbRLOSh003ekF8geIIL8=.9078c0a3-d727-49b3-9f74-7cefc14781d6@github.com>

On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Update looks good.
Testing results are also good.

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

Marked as reviewed by kvn (Reviewer).

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

From shade at openjdk.java.net  Wed Mar 23 07:27:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Mar 2022 07:27:33 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4]
In-Reply-To: <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>
Message-ID: <15WaiDnekvPCVSDawjOcu92JSwMFrdpn-bOEycOwIYc=.a69bf14a-082a-46c5-8a72-56d15c2d4142@github.com>

On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
>> 
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
>> 
>> [1] https://openjdk.java.net/jeps/422
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Looks okay to me.

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

Marked as reviewed by shade (Reviewer).

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

From mcimadamore at openjdk.java.net  Wed Mar 23 14:06:56 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 23 Mar 2022 14:06:56 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop redundant javadoc statements re. handling of nulls
  (handling of nulls is specified once and for all in the package javadoc)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/7ec71f73..c9bc9a70

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

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

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

From fyang at openjdk.java.net  Thu Mar 24 07:01:43 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 24 Mar 2022 07:01:43 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v5]
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <ybE2QYYZQ6GU7o67rW5rpgA3JGxULHDGlTUTi-2cky8=.488673b2-40fe-49d3-9076-ac4c2b10efe0@github.com>

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8276799
 - Fix copyright header
 - Address review comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8276799
 - 8276799: Implementation of JEP 422: Linux/RISC-V Port

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6294/files
  - new: https://git.openjdk.java.net/jdk/pull/6294/files/d8bef7fa..90db70eb

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

  Stats: 3082 lines in 147 files changed: 1635 ins; 374 del; 1073 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294

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

From fyang at openjdk.java.net  Thu Mar 24 07:01:44 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 24 Mar 2022 07:01:44 GMT
Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4]
In-Reply-To: <q-UVp-aGUKl2f80QbmVJcfYcbRLOSh003ekF8geIIL8=.9078c0a3-d727-49b3-9f74-7cefc14781d6@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
 <H6k4_7Va_pUcf-Dl_mH4S1ognsPRrKdpsiotq6_7-Lk=.dad178f6-24fe-4451-98ea-4a3479fe7661@github.com>
 <q-UVp-aGUKl2f80QbmVJcfYcbRLOSh003ekF8geIIL8=.9078c0a3-d727-49b3-9f74-7cefc14781d6@github.com>
Message-ID: <Va60SmhN5tJ-p3xBLCMv3PmZgrGIkShL3SH8farb_Go=.59bd6ec7-d5a7-47d7-ac87-f7ed8eacfa37@github.com>

On Wed, 23 Mar 2022 02:17:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright header
>
> Update looks good.
> Testing results are also good.

@vnkozlov @shipilev : Thanks for reviewing this :-)

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

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

From fyang at openjdk.java.net  Thu Mar 24 09:26:53 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 24 Mar 2022 09:26:53 GMT
Subject: Integrated: 8276799: Implementation of JEP 422: Linux/RISC-V Port
In-Reply-To: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
References: <U63ZsjFbn1joXn0DetupOhRJ6JHRe0MElXMuJzST7gI=.0f7c3d12-bad0-4706-92a8-139bf33dd8ba@github.com>
Message-ID: <_xdzQDldAoyV0WBzaIMiT4tJWdNzOsP5JO-QuRhm2Z4=.da6e619a-2948-4886-878a-6feaa09e48c4@github.com>

On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang <fyang at openjdk.org> wrote:

> This PR implements JEP 422: Linux/RISC-V Port [1].
> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch.
> 
> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs.
> 
> [1] https://openjdk.java.net/jeps/422

This pull request has now been integrated.

Changeset: 5905b02c
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5905b02c0e2643ae8d097562f181953f6c88fc89
Stats:     59141 lines in 188 files changed: 58964 ins; 54 del; 123 mod

8276799: Implementation of JEP 422: Linux/RISC-V Port

Co-authored-by: Yadong Wang <yadonn.wang at huawei.com>
Co-authored-by: Yanhong Zhu <zhuyanhong2 at huawei.com>
Co-authored-by: Feilong Jiang <jiangfeilong at huawei.com>
Co-authored-by: Kun Wang <wangkun49 at huawei.com>
Co-authored-by: Zhuxuan Ni <nizhuxuan at huawei.com>
Co-authored-by: Taiping Guo <guotaiping1 at huawei.com>
Co-authored-by: Kang He <hekang6 at huawei.com>
Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Co-authored-by: Xiaolin Zheng <yunyao.zxl at alibaba-inc.com>
Co-authored-by: Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: ihse, dholmes, rriggs, kvn, shade

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

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

From jvernee at openjdk.java.net  Thu Mar 24 13:16:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 13:16:53 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
Message-ID: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>

On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop redundant javadoc statements re. handling of nulls
>   (handling of nulls is specified once and for all in the package javadoc)

Some more nits.

One potential issue with adding --enable-preview when building benchmarks (last comment of the bunch). 

Other than that, I think this looks good.

make/test/BuildMicrobenchmark.gmk line 97:

> 95:     SRC := $(MICROBENCHMARK_SRC), \
> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \

It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 61:

> 59:  *     <li>{@linkplain MemorySegment#allocateNative(long, long, MemorySession) native memory segments}, backed by off-heap memory;</li>
> 60:  *     <li>{@linkplain FileChannel#map(FileChannel.MapMode, long, long, MemorySession) mapped memory segments}, obtained by mapping
> 61:  * a file into main memory ({@code mmap}); tha contents of a mapped memory segments can be {@linkplain #force() persisted} and

Suggestion:

 * a file into main memory ({@code mmap}); the contents of a mapped memory segments can be {@linkplain #force() persisted} and

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 298:

> 296: 
> 297:     /**
> 298:      * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address

Saw a similar change in other places, so I'll suggest this here as well.
Suggestion:

     * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 311:

> 309: 
> 310:     /**
> 311:      * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address

Suggestion:

     * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 143:

> 141: 
> 142:     /**
> 143:      * {@return the owner thread associated with this memory session (if any)}

Maybe the "if any" here could be more specific. e.g. saying that `null` is returned if the session doesn't have an owner thread.

src/java.base/share/classes/java/lang/foreign/MemorySession.java line 165:

> 163: 
> 164:     /**
> 165:      * Closes this memory session. As a side effect, if this operation completes without exceptions, this session

I'd suggest change this to "As a result of this", since the effects listed are the main reason for closing a session. (it strikes me as strange. If the things listed are side-effects, then what is the main effect of closing a segment?)
Suggestion:

     * Closes this memory session. As a result of this, if this operation completes without exceptions, this session

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 51:

> 49:  * <p>
> 50:  * Clients can obtain a {@linkplain #loaderLookup() loader lookup},
> 51:  * which can be used to search symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)},

"search symbols" sounds a bit unnatural to me... I like the wording in the libraryLookup doc more
Suggestion:

 * which can be used to find symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)},

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 59:

> 57:  * <p>
> 58:  * Finally, clients can load a library and obtain a {@linkplain #libraryLookup(Path, MemorySession) library lookup} which can be used
> 59:  * to search symbols in that library. A library lookup is associated with a {@linkplain  MemorySession memory session},

Suggestion:

 * to find symbols in that library. A library lookup is associated with a {@linkplain  MemorySession memory session},

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7895:

> 7893:      *     VarHandle handle = MethodHandles.memorySegmentViewVarHandle(ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN)); //(MemorySegment, long) -> int
> 7894:      *     handle = MethodHandles.insertCoordinates(handle, 1, 4); //(MemorySegment) -> int
> 7895:      * }</pre></blockquote>

These could be snippets.

Also, I think it would be nice to add a link to MemoryLayout.varHandle here.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 975:

> 973:     /**
> 974:      * Maps a region of this channel's file into a new mapped memory segment,
> 975:      * with a given offset, size and memory session.

Suggestion:

     * with the given offset, size and memory session.

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 51:

> 49: 
> 50:     /* A fallback lookup, used when creation of system lookup fails. */
> 51:     private static final Function<String, Optional<MemorySegment>> fallbackLookup = name -> Optional.empty();

Now that we have SymbolLookup again, these Function types could potentially be changed to SymbolLookup again. (and also avoid some churn here)

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135:

> 133:     }
> 134: 
> 135:     public Optional<MemorySegment> lookup(String name) {

`@Override` here?

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071:

> 1069:         sessionImpl.checkValidStateSlow();
> 1070:         if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0.");
> 1071:         if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0.");

The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing?

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

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

From kdnilsen at openjdk.java.net  Thu Mar 24 17:37:57 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 24 Mar 2022 17:37:57 GMT
Subject: RFR: Balance evacuation
Message-ID: <VkLMqGE7ncAk8Pgg2Rw__766GQ7qIKuXrpG9cIV88s4=.767b192b-3a2e-4a0a-ab1f-8d6e0bf16e79@github.com>

We found that a cause for too-frequent degenerated GCs was allocation failures during evacuation.  We chased this down to two root causes, both of which are addressed in this new commit:

1. When thread-local promotion labs (PLAB and GCLAB) are allowed to expand indiscriminately, we end up with a situation under which a small number of threads hold too much of the evacuation budget within their private caches, leaving other threads unable to allocate memory to hold evacuation copies.  This is addressed by introducing a new ShenandoahMaxEvacLABRatio parameter, with default value 16.

2. Enforcement of evacuation budgets was previously introduced into the generational mode of Shenandoah.  This allows more proactive management of available memory resources during particular phases of operation.  For example, it allows us to safely loan memory from old-gen to young-gen during evacuation and update-refs phases of execution.  However, with this enforcement, we found that the default values for ShenandoahEvacWaste that work well with traditional Shenandoah are too low for generational mode of Shenandoah.  So we introduced a new ShenandoahGenerationalEvacWaste parameter with default value 2.0.

This branch has been tested on a variety of workloads and shown to reduce the number of degenerated GCs with generational mode of Shenandoah below the values of traditional Shenandoah for most cases (holding heap size constant).

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

Commit messages:
 - Increase default value of ShenandoahGenerationalEvacWaste
 - Merge branch 'shenandoah' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into rectify-evacuation-imbalance
 - Merge upstream  into shenandoah
 - Merge upstream into shenandoah
 - Add options to control evacuation efficiency
 - Revert "Mutator may fail to evacuate"

Changes: https://git.openjdk.java.net/shenandoah/pull/127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=127&range=00
  Stats: 49 lines in 2 files changed: 46 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/127.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/127/head:pull/127

PR: https://git.openjdk.java.net/shenandoah/pull/127

From mcimadamore at openjdk.java.net  Thu Mar 24 17:57:16 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 17:57:16 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v6]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UlF0pUMIRsWi9nKnoi4uxDWW1LYqj5VIsFU5PG797ms=.80afd075-e9fc-42e1-aa35-6b792ab5d1f2@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9bc9a70..95f65eea

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 17:57:19 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 17:57:19 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
Message-ID: <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>

On Thu, 24 Mar 2022 13:10:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop redundant javadoc statements re. handling of nulls
>>   (handling of nulls is specified once and for all in the package javadoc)
>
> make/test/BuildMicrobenchmark.gmk line 97:
> 
>> 95:     SRC := $(MICROBENCHMARK_SRC), \
>> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \
> 
> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.

Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.

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

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

From wkemper at openjdk.java.net  Thu Mar 24 18:05:11 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 24 Mar 2022 18:05:11 GMT
Subject: RFR: Balance evacuation
In-Reply-To: <VkLMqGE7ncAk8Pgg2Rw__766GQ7qIKuXrpG9cIV88s4=.767b192b-3a2e-4a0a-ab1f-8d6e0bf16e79@github.com>
References: <VkLMqGE7ncAk8Pgg2Rw__766GQ7qIKuXrpG9cIV88s4=.767b192b-3a2e-4a0a-ab1f-8d6e0bf16e79@github.com>
Message-ID: <dN36JjhGmDpa1rXOZYfhagT25pzSOLgtV9LPj-BtLv4=.5753758c-c046-4908-adf1-4212b972dcd5@github.com>

On Thu, 24 Mar 2022 17:31:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We found that a cause for too-frequent degenerated GCs was allocation failures during evacuation.  We chased this down to two root causes, both of which are addressed in this new commit:
> 
> 1. When thread-local promotion labs (PLAB and GCLAB) are allowed to expand indiscriminately, we end up with a situation under which a small number of threads hold too much of the evacuation budget within their private caches, leaving other threads unable to allocate memory to hold evacuation copies.  This is addressed by introducing a new ShenandoahMaxEvacLABRatio parameter, with default value 16.
> 
> 2. Enforcement of evacuation budgets was previously introduced into the generational mode of Shenandoah.  This allows more proactive management of available memory resources during particular phases of operation.  For example, it allows us to safely loan memory from old-gen to young-gen during evacuation and update-refs phases of execution.  However, with this enforcement, we found that the default values for ShenandoahEvacWaste that work well with traditional Shenandoah are too low for generational mode of Shenandoah.  So we introduced a new ShenandoahGenerationalEvacWaste parameter with default value 2.0.
> 
> This branch has been tested on a variety of workloads and shown to reduce the number of degenerated GCs with generational mode of Shenandoah below the values of traditional Shenandoah for most cases (holding heap size constant).

Marked as reviewed by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 488:

> 486:     _old_generation->initialize_heuristics(_gc_mode);
> 487: 
> 488:     ShenandoahEvacWaste = ShenandoahGenerationalEvacWaste;

Minor nit, but this would fit better in `ShenandoahGenerationalMode::initialize_flags`.

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

PR: https://git.openjdk.java.net/shenandoah/pull/127

From mcimadamore at openjdk.java.net  Thu Mar 24 18:19:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:19:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v7]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <Dk4tijedl7MZ4TwIOY4TojoGpkUB53aRHaQ3WYvTWTY=.2446002d-771d-4eda-8798-104f828b883e@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/95f65eea..3e8cfd74

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

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 18:19:12 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:19:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
Message-ID: <BF7C3WgLSzE3-OI4ffG0ThctsxSZmDGOuSyRxdO_8L8=.53a9f38d-08d8-4a69-9182-f7a240444b14@github.com>

On Thu, 24 Mar 2022 13:00:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop redundant javadoc statements re. handling of nulls
>>   (handling of nulls is specified once and for all in the package javadoc)
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071:
> 
>> 1069:         sessionImpl.checkValidStateSlow();
>> 1070:         if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0.");
>> 1071:         if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0.");
> 
> The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing?

`mapInternal` in FileChannelImpl takes care of that for both flavors of `map`

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

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

From jvernee at openjdk.java.net  Thu Mar 24 18:38:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 18:38:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
Message-ID: <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>

On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> make/test/BuildMicrobenchmark.gmk line 97:
>> 
>>> 95:     SRC := $(MICROBENCHMARK_SRC), \
>>> 96:     BIN := $(MICROBENCHMARK_CLASSES), \
>>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \
>> 
>> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version.
>
> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.

I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:


diff --git a/make/RunTests.gmk b/make/RunTests.gmk
index 81540266ec0..9ed45fb02a8 100644
--- a/make/RunTests.gmk
+++ b/make/RunTests.gmk
@@ -583,7 +583,7 @@ define SetupRunMicroTestBody
   $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))

   # Current tests needs to open java.io
-  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
+  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview

   # Save output as JSON or CSV file
   ifneq ($$(MICRO_RESULTS_FORMAT), )


People manually running the benchmarks.jar will have to pass `--enable-preview` still though.

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 18:59:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:59:11 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v8]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <6yP7vgmmPmX36zl3Lp0Dxw48sxlimGcfvOI0YrM4Bt0=.86078fb2-182d-44a1-b861-a7a234073f40@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/3e8cfd74..6881b6dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=06-07

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:05:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:05:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v9]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <bK3ZUgWiUICbQoH6BAXaMVvozl-8K3QSP-r8i3s73R8=.62c1679c-bef6-4c61-9649-ee0b49619e11@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address more review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6881b6dc..d95c6d0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07-08

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:12:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:12:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v10]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <IbzbMQh8itf1bZDG2NW9koTmFnZBZy4p793Ia9rqmYI=.5821acaa-a4ca-4f7a-8335-36f9be6e41a1@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add --enable-preview to micro benchmark java options

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/d95c6d0f..6e7189b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08-09

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:27:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:27:21 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v11]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to RunTests.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/6e7189b4..504b564a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09-10

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

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

From jvernee at openjdk.java.net  Thu Mar 24 19:27:22 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 19:27:22 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v11]
In-Reply-To: <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <sqYi7QOy93LHy2hsoiN3yxBl-d_xn5ERQ0dcUxp6Lss=.05c0c823-d8d1-415b-9e44-2ddf7cdf1806@github.com>
Message-ID: <EU8pU4FOUDRFJLT36VCNphal4tKZakWcpxu7QavBUtM=.86052746-8cf2-444d-b59d-717c185c40de@github.com>

On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to RunTests.gmk

Looks Good!

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

Marked as reviewed by jvernee (Reviewer).

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

From jvernee at openjdk.java.net  Thu Mar 24 19:27:23 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 19:27:23 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
 <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
Message-ID: <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>

On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well.
>
> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:
> 
> 
> diff --git a/make/RunTests.gmk b/make/RunTests.gmk
> index 81540266ec0..9ed45fb02a8 100644
> --- a/make/RunTests.gmk
> +++ b/make/RunTests.gmk
> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody
>    $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))
> 
>    # Current tests needs to open java.io
> -  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
> +  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview
> 
>    # Save output as JSON or CSV file
>    ifneq ($$(MICRO_RESULTS_FORMAT), )
> 
> 
> People manually running the benchmarks.jar will have to pass `--enable-preview` still though.

After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted.

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

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

From mcimadamore at openjdk.java.net  Thu Mar 24 19:27:24 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 19:27:24 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v5]
In-Reply-To: <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <YrFMVDRPFM3j1QSRWz4HTAC_StnEZqKhtQh2d4giPQ0=.8d5d0129-7eec-46da-a7e6-cac411ae59bb@github.com>
 <rPhKrcAElzIIqqrCHEWTnQholmFVDasGQvRQFUvSVBE=.4e30d8f8-9528-4e02-bf66-fbebdbb4d43e@github.com>
 <lf6GY2zS__SdNbSyt_Q9AMwzqlkm7EAMuZfT6_QqRQ8=.c29a3ed3-aa10-41e0-8a92-5a498d8dd2dc@github.com>
 <HP8E1i63YawWS0a5npsNGgPjMK3JJ5f8-KHOAetsmzw=.788c3473-0b64-423e-bfff-054aad1e69b8@github.com>
 <AeMdR84caksIk-YkuMEQ3zmHwU2BazSNx8CHO34Tts0=.71fb91b5-ef10-4961-975c-a34897b80fa3@github.com>
Message-ID: <cRZrwXe67GkRYGSFqF2JOz4H2xfx8XNi_JwTcBj_ZVw=.b7b983b3-a936-44e4-be48-1886c852d0e6@github.com>

On Thu, 24 Mar 2022 19:17:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick:
>> 
>> 
>> diff --git a/make/RunTests.gmk b/make/RunTests.gmk
>> index 81540266ec0..9ed45fb02a8 100644
>> --- a/make/RunTests.gmk
>> +++ b/make/RunTests.gmk
>> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody
>>    $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS))
>> 
>>    # Current tests needs to open java.io
>> -  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED
>> +  $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview
>> 
>>    # Save output as JSON or CSV file
>>    ifneq ($$(MICRO_RESULTS_FORMAT), )
>> 
>> 
>> People manually running the benchmarks.jar will have to pass `--enable-preview` still though.
>
> After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted.

Turns out this is no longer necessary. As part of the support for preview API, javac now only pollutes the classfile if a source file is using preview features, as described in this PR:
https://github.com/openjdk/jdk/pull/703

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

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

From kdnilsen at openjdk.java.net  Thu Mar 24 23:37:24 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 24 Mar 2022 23:37:24 GMT
Subject: Integrated: Balance evacuation
In-Reply-To: <VkLMqGE7ncAk8Pgg2Rw__766GQ7qIKuXrpG9cIV88s4=.767b192b-3a2e-4a0a-ab1f-8d6e0bf16e79@github.com>
References: <VkLMqGE7ncAk8Pgg2Rw__766GQ7qIKuXrpG9cIV88s4=.767b192b-3a2e-4a0a-ab1f-8d6e0bf16e79@github.com>
Message-ID: <mflGeqV8ziC05o-T12KraiowmgGBG6bSdJpxi4xDAfM=.7841c295-714d-4f05-8a8a-6ac456796e16@github.com>

On Thu, 24 Mar 2022 17:31:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We found that a cause for too-frequent degenerated GCs was allocation failures during evacuation.  We chased this down to two root causes, both of which are addressed in this new commit:
> 
> 1. When thread-local promotion labs (PLAB and GCLAB) are allowed to expand indiscriminately, we end up with a situation under which a small number of threads hold too much of the evacuation budget within their private caches, leaving other threads unable to allocate memory to hold evacuation copies.  This is addressed by introducing a new ShenandoahMaxEvacLABRatio parameter, with default value 16.
> 
> 2. Enforcement of evacuation budgets was previously introduced into the generational mode of Shenandoah.  This allows more proactive management of available memory resources during particular phases of operation.  For example, it allows us to safely loan memory from old-gen to young-gen during evacuation and update-refs phases of execution.  However, with this enforcement, we found that the default values for ShenandoahEvacWaste that work well with traditional Shenandoah are too low for generational mode of Shenandoah.  So we introduced a new ShenandoahGenerationalEvacWaste parameter with default value 2.0.
> 
> This branch has been tested on a variety of workloads and shown to reduce the number of degenerated GCs with generational mode of Shenandoah below the values of traditional Shenandoah for most cases (holding heap size constant).

This pull request has now been integrated.

Changeset: 5fd97640
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/5fd97640bc0f21d1f5512a84f1548add89486ea3
Stats:     49 lines in 2 files changed: 46 ins; 2 del; 1 mod

Balance evacuation

Reviewed-by: wkemper

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

PR: https://git.openjdk.java.net/shenandoah/pull/127

From duke at openjdk.java.net  Fri Mar 25 15:14:52 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 25 Mar 2022 15:14:52 GMT
Subject: Withdrawn: 8280579: Shenandoah: Skip regions in the back of sorted
 array when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <KEFFcI8zAYfNtDvAzGeKLyNbIYfwzbhFgnFSsJWXTO0=.3114f53c-a620-40a8-b95f-2d068d7ba9fa@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

This pull request has been closed without being integrated.

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

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

From rkennke at redhat.com  Fri Mar 25 15:21:26 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 25 Mar 2022 16:21:26 +0100
Subject: Merging gc state tests for two dependent loads
In-Reply-To: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>
References: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>
Message-ID: <2cb8543b-48f3-9750-31f8-d22b822a244d@redhat.com>

Hello Yude,

I have analyzed the full disassembly of that method:

https://gist.github.com/rkennke/e2610ec8b87e481edc2ebfe66f98c1a0

The problem is here:

   0x00007f2621981d2b:   mov    0x2b0(%r15),%rsi
   0x00007f2621981d32:   mov    (%rsi),%rbx
<--- Seemingly missing LRB here --->
   0x00007f2621981d35:   mov    0x58(%rbx),%r13 
;*invokestatic currentThread {reexecute=0 rethrow=0 return_oop=0}
                                                             ; - 
java.lang.ThreadLocal::set at 0 (line 219)
   0x00007f2621981d39:   testb  $0x1,0x20(%r15)
   0x00007f2621981d3e:   jne    0x00007f2621981df1

The merged LRBs are found at 0x00007f2621981df1:

;; B14: #	out( B27 B15 ) <- in( B1 )  Freq: 0,000999987
<--- LRB mid-path for %rbx --->
   0x00007f2621981df1:   mov    %rbx,%r10
   0x00007f2621981df4:   shr    $0x16,%r10
   0x00007f2621981df8:   cmpb   $0x0,0x10000(%r10)
   0x00007f2621981e00:   jne    0x00007f2621981f34 
;*invokestatic currentThread {reexecute=0 rethrow=0 return_oop=0}
                                                             ; - 
java.lang.ThreadLocal::set at 0 (line 219)
  ;; B15: #	out( B28 B16 ) <- in( B14 B27 )  Freq: 0,000999987
<--- LRB midpath for %13 --->
   0x00007f2621981e06:   mov    %r13,%r10
   0x00007f2621981e09:   shr    $0x16,%r10
   0x00007f2621981e0d:   cmpb   $0x0,0x10000(%r10)
   0x00007f2621981e15:   jne    0x00007f2621981f50


Now, the *slow* paths are here:

; B27: #	out( B15 ) <- in( B14 )  Freq: 9,99974e-07
   0x00007f2621981f34:   mov    %rbx,%rdi
   0x00007f2621981f37:   movabs $0x7f2634778de0,%r10
   0x00007f2621981f41:   callq  *%r10
   0x00007f2621981f44:   mov    %rax,%rbx
<--- Reloads %r13 if necessary --->
   0x00007f2621981f47:   mov    0x58(%rbx),%r13
   0x00007f2621981f4b:   jmpq   0x00007f2621981e06


IOW, the fast-path speculatively assumes that GC is inactive, and fixes 
it in the slow-path, by re-doing the "mov 0x58(%rbx),%r13" when necessary.

@Roland can you confirm this?

Thanks,
Roman


> Copied from 8283243 for visibility:
> 
> --------
> 
> Shenandoah will merge two gc state tests (from two LRBs) if they satisfy certain control flow constraint (in ShenandoahBarrierC2Support::merge_back_to_back_tests). I think there could be an issue if the two loads the two LRBs guard are dependent.
> 
> To reproduce, I ran java -XX:-UseCompressedOops -XX:+UseShenandoahGC -XX:CompileCommand=print,*ThreadLocal.set -jar SPECjvm2008.jar -coe -ict -ikv -i 2 -bt 8 derby
> 
> The C2 outcome for ThreadLocal.set has:
> 
> ..
>    0: mov 0x268(%r15),%rsi ; Thread t = Thread.currentThread(); // get oop handle
>    1: mov (%rsi),%r12 ; Thread t = Thread.currentThread(); // get oop out of oop handle
>    2: mov 0x58(%r12),%rbx ; ThreadLocalMap map = getMap(t);
>    3: nopl 0x0(%rax)
>    4: testb $0x1,0x20(%r15) ; gc state test is too late here
>    5: jne 0x00007f0a3508f6e7
> ..
> 
> There is no barrier between line 1 and line 2. There was a barrier, but it was merged with the barrier for line 2, (the gc state tests are merged) and the merged test is placed at line 4. The problem is line 2 could visit from-space object and get outdated data.
> 
> If I comment out the call to ShenandoahBarrierC2Support::merge_back_to_back_tests, the outcome is more like what I expected:
> 
> ..
>    0: mov 0x268(%r15),%rsi
>    1: mov (%rsi),%r12
>    2: nopw 0x0(%rax,%rax,1)
>    3: testb $0x1,0x20(%r15) ; first gc state test
>    4: jne 0x00007ff55d077207
>    5: mov 0x58(%r12),%rbx
>    6: testb $0x1,0x20(%r15) ; second gc state test
>    7: jne 0x00007ff55d077235
> ..
> 
> I think the merging didn't consider that the second load could use the result from the first load (in this case, r12). Can anyone confirm if this is an issue?


From kdnilsen at openjdk.java.net  Fri Mar 25 19:30:32 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 25 Mar 2022 19:30:32 GMT
Subject: RFR: Revert "Mutator may fail to evacuate"
In-Reply-To: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
References: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
Message-ID: <JUScpHfxzgLSGW0byBwlXLjoFDZUkiZW-1t3txium4o=.81e1e8ec-b4f2-4562-b96b-090049f534ac@github.com>

On Tue, 8 Mar 2022 23:58:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reverts commit 2132a6d151e4c46b71a220100fa478a8be676f13.
> 
> We found that the solution implemented in this commit is insufficient to address the problem.  We need to redesign the OOM protocol for evacuation allocation failures.  This is being explored by other engineers.

This code was reverted on a different pull request.

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

PR: https://git.openjdk.java.net/shenandoah/pull/123

From kdnilsen at openjdk.java.net  Fri Mar 25 19:30:32 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 25 Mar 2022 19:30:32 GMT
Subject: Withdrawn: Revert "Mutator may fail to evacuate"
In-Reply-To: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
References: <xfvlMWXS0df1OkvIqJLb9DaseUhylOgq7rF8xCUBztU=.c28a5ba4-a71d-4187-b673-c174deb435aa@github.com>
Message-ID: <eCTk4AuRbYu4VS4GYgucDWakjsWxVAuVxlEz-zlGREI=.82b3cf57-3b0e-4a3f-8a13-7c7b674c81b5@github.com>

On Tue, 8 Mar 2022 23:58:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This reverts commit 2132a6d151e4c46b71a220100fa478a8be676f13.
> 
> We found that the solution implemented in this commit is insufficient to address the problem.  We need to redesign the OOM protocol for evacuation allocation failures.  This is being explored by other engineers.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/shenandoah/pull/123

From yude.lyd at alibaba-inc.com  Mon Mar 28 02:43:04 2022
From: yude.lyd at alibaba-inc.com (Yude Lin)
Date: Mon, 28 Mar 2022 10:43:04 +0800
Subject: =?UTF-8?B?UmU6IE1lcmdpbmcgZ2Mgc3RhdGUgdGVzdHMgZm9yIHR3byBkZXBlbmRlbnQgbG9hZHM=?=
In-Reply-To: <2cb8543b-48f3-9750-31f8-d22b822a244d@redhat.com>
References: <a788ef04-af16-444b-bbaa-cfc42b2dade3.yude.lyd@alibaba-inc.com>,
 <2cb8543b-48f3-9750-31f8-d22b822a244d@redhat.com>
Message-ID: <f27ae68a-8a2d-453f-be9e-31ac67c5f629.yude.lyd@alibaba-inc.com>

Hi Roman,

I can confirm there is a reload. That explains many things. Thanks for bothering with the detailed analysis : )

Regards,
Yude


------------------------------------------------------------------
From:Roman Kennke <rkennke at redhat.com>
Send Time:2022?3?25?(???) 23:21
To:???(??) <yude.lyd at alibaba-inc.com>; shenandoah-dev <shenandoah-dev at openjdk.java.net>; rwestrel <rwestrel at redhat.com>
Subject:Re: Merging gc state tests for two dependent loads

Hello Yude,

I have analyzed the full disassembly of that method:

https://gist.github.com/rkennke/e2610ec8b87e481edc2ebfe66f98c1a0

The problem is here:

   0x00007f2621981d2b:   mov    0x2b0(%r15),%rsi
   0x00007f2621981d32:   mov    (%rsi),%rbx
<--- Seemingly missing LRB here --->
   0x00007f2621981d35:   mov    0x58(%rbx),%r13 
;*invokestatic currentThread {reexecute=0 rethrow=0 return_oop=0}
                                                             ; - 
java.lang.ThreadLocal::set at 0 (line 219)
   0x00007f2621981d39:   testb  $0x1,0x20(%r15)
   0x00007f2621981d3e:   jne    0x00007f2621981df1

The merged LRBs are found at 0x00007f2621981df1:

;; B14: # out( B27 B15 ) <- in( B1 )  Freq: 0,000999987
<--- LRB mid-path for %rbx --->
   0x00007f2621981df1:   mov    %rbx,%r10
   0x00007f2621981df4:   shr    $0x16,%r10
   0x00007f2621981df8:   cmpb   $0x0,0x10000(%r10)
   0x00007f2621981e00:   jne    0x00007f2621981f34 
;*invokestatic currentThread {reexecute=0 rethrow=0 return_oop=0}
                                                             ; - 
java.lang.ThreadLocal::set at 0 (line 219)
  ;; B15: # out( B28 B16 ) <- in( B14 B27 )  Freq: 0,000999987
<--- LRB midpath for %13 --->
   0x00007f2621981e06:   mov    %r13,%r10
   0x00007f2621981e09:   shr    $0x16,%r10
   0x00007f2621981e0d:   cmpb   $0x0,0x10000(%r10)
   0x00007f2621981e15:   jne    0x00007f2621981f50


Now, the *slow* paths are here:

; B27: # out( B15 ) <- in( B14 )  Freq: 9,99974e-07
   0x00007f2621981f34:   mov    %rbx,%rdi
   0x00007f2621981f37:   movabs $0x7f2634778de0,%r10
   0x00007f2621981f41:   callq  *%r10
   0x00007f2621981f44:   mov    %rax,%rbx
<--- Reloads %r13 if necessary --->
   0x00007f2621981f47:   mov    0x58(%rbx),%r13
   0x00007f2621981f4b:   jmpq   0x00007f2621981e06


IOW, the fast-path speculatively assumes that GC is inactive, and fixes 
it in the slow-path, by re-doing the "mov 0x58(%rbx),%r13" when necessary.

@Roland can you confirm this?

Thanks,
Roman


> Copied from 8283243 for visibility:
> 
> --------
> 
> Shenandoah will merge two gc state tests (from two LRBs) if they satisfy certain control flow constraint (in ShenandoahBarrierC2Support::merge_back_to_back_tests). I think there could be an issue if the two loads the two LRBs guard are dependent.
> 
> To reproduce, I ran java -XX:-UseCompressedOops -XX:+UseShenandoahGC -XX:CompileCommand=print,*ThreadLocal.set -jar SPECjvm2008.jar -coe -ict -ikv -i 2 -bt 8 derby
> 
> The C2 outcome for ThreadLocal.set has:
> 
> ..
>    0: mov 0x268(%r15),%rsi ; Thread t = Thread.currentThread(); // get oop handle
>    1: mov (%rsi),%r12 ; Thread t = Thread.currentThread(); // get oop out of oop handle
>    2: mov 0x58(%r12),%rbx ; ThreadLocalMap map = getMap(t);
>    3: nopl 0x0(%rax)
>    4: testb $0x1,0x20(%r15) ; gc state test is too late here
>    5: jne 0x00007f0a3508f6e7
> ..
> 
> There is no barrier between line 1 and line 2. There was a barrier, but it was merged with the barrier for line 2, (the gc state tests are merged) and the merged test is placed at line 4. The problem is line 2 could visit from-space object and get outdated data.
> 
> If I comment out the call to ShenandoahBarrierC2Support::merge_back_to_back_tests, the outcome is more like what I expected:
> 
> ..
>    0: mov 0x268(%r15),%rsi
>    1: mov (%rsi),%r12
>    2: nopw 0x0(%rax,%rax,1)
>    3: testb $0x1,0x20(%r15) ; first gc state test
>    4: jne 0x00007ff55d077207
>    5: mov 0x58(%r12),%rbx
>    6: testb $0x1,0x20(%r15) ; second gc state test
>    7: jne 0x00007ff55d077235
> ..
> 
> I think the merging didn't consider that the second load could use the result from the first load (in this case, r12). Can anyone confirm if this is an issue?

From mcimadamore at openjdk.java.net  Tue Mar 29 18:13:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 18:13:05 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v12]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <VrBKvqY2VPw610lAb_DQ67oJoPUKg8gY1NfbQtDompc=.302e1c5e-0577-4e19-a963-3e137c2f2879@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore 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 27 additional commits since the last revision:

 - Use thread local storage to optimize attach of async threads
 - Drop support for Constable from MemoryLayout/FunctionDescriptor
 - Merge branch 'master' into foreign-preview
 - Revert changes to RunTests.gmk
 - Add --enable-preview to micro benchmark java options
 - Address more review comments
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Address review comments
 - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/02333d66...55aee872

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/504b564a..55aee872

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10-11

  Stats: 99257 lines in 1550 files changed: 79659 ins; 15544 del; 4054 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From mcimadamore at openjdk.java.net  Tue Mar 29 18:23:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 18:23:41 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v13]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <w1LIgrpX4jp0zQM5bnopMS4X7F2Tedv1heD_crujzLg=.eaef7a80-78c1-4d82-9d5b-9151793c587a@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Switch to daemon threads for async upcalls

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/55aee872..43dc6be3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11-12

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 18:06:28 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 18:06:28 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v14]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UUVSVqArxsxmgZm4nRpTMSOOP7TBU-HAlliRgnZj3nA=.7c2577cd-3275-4711-8250-5f3f9177cd4f@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix bad usage of `@link` with primitive array types

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/43dc6be3..0bcc8664

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12-13

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 20:59:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 20:59:34 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v15]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak FunctionDescriptor::argumentLayouts to return an immutable list

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/0bcc8664..af41a76c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13-14

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

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

From mcimadamore at openjdk.java.net  Wed Mar 30 21:51:16 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 21:51:16 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v16]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into foreign-preview
 - Tweak FunctionDescriptor::argumentLayouts to return an immutable list
 - Fix bad usage of `@link` with primitive array types
 - Switch to daemon threads for async upcalls
 - Use thread local storage to optimize attach of async threads
 - Drop support for Constable from MemoryLayout/FunctionDescriptor
 - Merge branch 'master' into foreign-preview
 - Revert changes to RunTests.gmk
 - Add --enable-preview to micro benchmark java options
 - Address more review comments
 - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=15
  Stats: 64862 lines in 366 files changed: 43028 ins; 19321 del; 2513 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

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

From duke at openjdk.java.net  Wed Mar 30 22:25:44 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 30 Mar 2022 22:25:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v15]
In-Reply-To: <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <ChILQVD6A1dP5zIu-XbL55gyACnJznvKj2As-xmN9zo=.77166bcb-2e43-4f23-b3e4-572bd0cb03c7@github.com>
Message-ID: <AGhJWXkbgskWwaMsytGJeljynUof-XLGCScTmUpJpdc=.e4254f87-bfec-42a9-8813-da67515d2e6d@github.com>

On Wed, 30 Mar 2022 20:59:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak FunctionDescriptor::argumentLayouts to return an immutable list

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 73:

> 71:      */
> 72:     public List<MemoryLayout> argumentLayouts() {
> 73:         return Collections.unmodifiableList(argLayouts);

This?change doesn?t?seem to?be?necessary, as?`FunctionDescriptor` is?already?created?with?`List.of(?)` (or?`Stream.toList()` in?the?case of?`FunctionDescriptor.VariadicFunction`), which?produce immutable?lists (although?`Stream.toList()` permits?`null`s, which?`Stream.collect(Collectors.toImmutableList())` and?`List.of(?)`?doesn?t).

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

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

From psandoz at openjdk.java.net  Wed Mar 30 22:44:42 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 30 Mar 2022 22:44:42 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v16]
In-Reply-To: <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <D_sTznfZ5MwQIq0R-E6xdlYDoMdB1zS4I9Fw4CPI4fE=.19016960-d411-4506-b323-b2d6b359c916@github.com>
Message-ID: <b6v4JeNodxX__cHxI3F3rGCRu8bB2o6_-9GEco-H-Sc=.4ba750f5-1ab2-4d6d-b16b-c108cc04222e@github.com>

On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Tweak FunctionDescriptor::argumentLayouts to return an immutable list
>  - Fix bad usage of `@link` with primitive array types
>  - Switch to daemon threads for async upcalls
>  - Use thread local storage to optimize attach of async threads
>  - Drop support for Constable from MemoryLayout/FunctionDescriptor
>  - Merge branch 'master' into foreign-preview
>  - Revert changes to RunTests.gmk
>  - Add --enable-preview to micro benchmark java options
>  - Address more review comments
>  - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5

Java code looks good (i did not go through the tests). As is common no comments, since code was reviewed in smaller steps in the panama-foreign respository.

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

Marked as reviewed by psandoz (Reviewer).

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