From mcimadamore at openjdk.java.net  Tue May  3 10:09:36 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:09:36 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v36]
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: <zBWrOVUAtzKYLgfMs09ANQNpmFvtpRZuyvlAvs6u2ec=.d88f6cfb-ee02-4b99-85dd-b997d39a718e@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/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/d1fcf012..dc309e8b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34-35

  Stats: 159 lines in 14 files changed: 96 ins; 8 del; 55 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 May  3 10:09:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:09:38 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v35]
In-Reply-To: <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
Message-ID: <wwsEntfub0DdNW9FidXoRV5KFsEuUCGj_d300HI4iVw=.d50ef030-6228-49a3-84c0-e7797598bf6a@github.com>

On Fri, 29 Apr 2022 08:15:32 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 Addressable javadoc

We've tweaked the support for looking up symbols in the standard libraries - `CLinker` used to implement `SymbolLookup`, now `CLinker` returns a "default lookup" instead. We've also greatly improved the javadoc of `SymbolLookup` - many thanks to Alex for the help! New javadoc here:

http://cr.openjdk.java.net/~mcimadamore/8282191/v3/javadoc/java.base/module-summary.html

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

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

From mcimadamore at openjdk.java.net  Tue May  3 10:40:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:40:02 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
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: <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@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 57 commits:

 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - Tweak Addressable javadoc
 - Downcall and upcall tests use wrong layout which is missing some trailing padding
 - Simplify libraryLookup impl
 - Address CSR comments
 - Merge branch 'master' into foreign-preview
 - Add ValueLayout changes
 - Tweak support for array element var handle
 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36
  Stats: 65464 lines in 367 files changed: 43470 ins; 19432 del; 2562 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 andrew at openjdk.java.net  Wed May  4 01:22:21 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 01:22:21 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 8285679: Fix regular expression
 used for tags on Shenandoah 8u tree
Message-ID: <c588848a-b774-49f6-988c-5ae4021dd57d@openjdk.org>

Changeset: a6ec29fc
Author:    Andrew Hughes <gnu.andrew at redhat.com>
Committer: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-04-17 15:28:50 +0000
URL:       https://git.openjdk.java.net/shenandoah-jdk8u/commit/a6ec29fc6beccae20353d9828d2a3a2ebeeb573e

8285679: Fix regular expression used for tags on Shenandoah 8u tree

Reviewed-by: rkennke

! .jcheck/conf


From erikj at openjdk.java.net  Wed May  4 14:06:23 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 4 May 2022 14:06:23 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions
In-Reply-To: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
Message-ID: <HTnNsRIkU7xchoh8L51jh7ClEtqfB7-9zcTyTSq25l0=.280f7ffa-beae-4d38-8a22-0f80e4debccd@github.com>

On Sun, 17 Apr 2022 15:12:42 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.
> 
> The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.
> 
> Thanks!

The .jcheck/conf file is still broken in this repo. Please run `git jcheck` in locally in the repo to see the exception.

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

PR: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3

From andrew at openjdk.java.net  Wed May  4 14:06:23 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 14:06:23 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using GitHub
 Actions
Message-ID: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>

Hi all,

This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.

The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.

Thanks!

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8253424
 - 8241768: git needs .gitattributes
 - Remove specification of minor version and package release data from GCC dependency
 - Fix JCheck tag regex
 - Backport 10029f784ef7be458a7b6ff3cc21649ff0abb6f3

Changes: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah-jdk8u&pr=3&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253424
  Stats: 3402 lines in 4 files changed: 3402 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah-jdk8u pull/3/head:pull/3

PR: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3

From andrew at openjdk.java.net  Wed May  4 14:06:24 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 14:06:24 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions
In-Reply-To: <HTnNsRIkU7xchoh8L51jh7ClEtqfB7-9zcTyTSq25l0=.280f7ffa-beae-4d38-8a22-0f80e4debccd@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
 <HTnNsRIkU7xchoh8L51jh7ClEtqfB7-9zcTyTSq25l0=.280f7ffa-beae-4d38-8a22-0f80e4debccd@github.com>
Message-ID: <4-ZHBtgCJVHUhZQbrPeCHwHKN6GXVeyWmWXnIih_muU=.0228cf17-d5a7-48a4-abc7-d2dffe9697cb@github.com>

On Mon, 25 Apr 2022 18:38:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The .jcheck/conf file is still broken in this repo. Please run `git jcheck` in locally in the repo to see the exception.

I have. I've fixed it locally and in this PR, but `jcheck` only picks it up when it's applied to the `master` branch. I guess I'll have to do another direct push with it. I'm waiting on ops to add `shenandoah8u332` to the list of JBS versions.

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

PR: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3

From andrew at openjdk.java.net  Wed May  4 14:06:25 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 14:06:25 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions
In-Reply-To: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
Message-ID: <Sd9dzhSt2qZOUb6nQYREeQCIHBGje7GFIMtVIHglM9U=.bf57f1ec-e057-4069-810d-31721c0e6490@github.com>

On Sun, 17 Apr 2022 15:12:42 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.
> 
> The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.
> 
> Thanks!

`git jcheck` is now passing locally. Will it re-run on this PR?

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

PR: https://git.openjdk.java.net/shenandoah-jdk8u/pull/3

From wkemper at openjdk.java.net  Wed May  4 16:30:27 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 4 May 2022 16:30:27 GMT
Subject: RFR: Have adaptive heuristic include only full cycles in average cycle
 time
Message-ID: <dNr6QQanDteXmZNmBlizZot9ThXl7ZqTqGpyPEsZtdQ=.d3b35926-d10a-46b8-9e3f-288c83ba40a3@github.com>

We have observed cases when a high percentage of short cut cycles (i.e., when evacuation and update reference phases are skipped) may cause the heuristic to believe it can complete _any_ cycle in the time it takes to complete an abbreviated cycle. Triggering the cycle too late may lead to a degenerated cycle. Abbreviated "learning cycles" are similarly ignored. 

A command line option has been added to disable this change in behavior and restore the previous behavior of including every cycle's time in the average time.

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

Commit messages:
 - Add feature flag to re-enable inclusion of all cycle times in heuristic
 - Only include full cycles in heuristic's average time

Changes: https://git.openjdk.java.net/shenandoah/pull/139/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=139&range=00
  Stats: 29 lines in 10 files changed: 15 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/139.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/139/head:pull/139

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

From zgu at openjdk.java.net  Wed May  4 16:44:19 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 4 May 2022 16:44:19 GMT
Subject: RFR: Have adaptive heuristic include only full cycles in average
 cycle time
In-Reply-To: <dNr6QQanDteXmZNmBlizZot9ThXl7ZqTqGpyPEsZtdQ=.d3b35926-d10a-46b8-9e3f-288c83ba40a3@github.com>
References: <dNr6QQanDteXmZNmBlizZot9ThXl7ZqTqGpyPEsZtdQ=.d3b35926-d10a-46b8-9e3f-288c83ba40a3@github.com>
Message-ID: <hXbPf60-jzP8dbRy7cjhWX1IrBT3i7hIXs0Dri1yyDM=.68036aa9-9714-4b2c-9a1e-ee7d62ebfd45@github.com>

On Wed, 4 May 2022 15:55:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We have observed cases when a high percentage of short cut cycles (i.e., when evacuation and update reference phases are skipped) may cause the heuristic to believe it can complete _any_ cycle in the time it takes to complete an abbreviated cycle. Triggering the cycle too late may lead to a degenerated cycle. Abbreviated "learning cycles" are similarly ignored. 
> 
> A command line option has been added to disable this change in behavior and restore the previous behavior of including every cycle's time in the average time.

LGTM

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

Marked as reviewed by zgu (Committer).

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

From duke at openjdk.java.net  Wed May  4 16:56:40 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 4 May 2022 16:56:40 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
Message-ID: <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>

On Tue, 3 May 2022 10:40:02 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 57 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Tweak support for Linker lookup
>    Improve javadoc of SymbolLookup
>  - Tweak Addressable javadoc
>  - Downcall and upcall tests use wrong layout which is missing some trailing padding
>  - Simplify libraryLookup impl
>  - Address CSR comments
>  - Merge branch 'master' into foreign-preview
>  - Add ValueLayout changes
>  - Tweak support for array element var handle
>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 116:

> 114:  * Linker nativeLinker = Linker.nativeLinker();
> 115:  * SymbolLookup stdlib = nativeLinker.defaultLookup();
> 116:  * MemorySegment malloc = stdlib.lookup("malloc");

This?should?be:
Suggestion:

 * Optional<MemorySegment> malloc = stdlib.lookup("malloc");

or
Suggestion:

 * MemorySegment malloc = stdlib.lookup("malloc").orElseThrow();

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:

> 151:     static SymbolLookup loaderLookup() {
> 152:         Class<?> caller = Reflection.getCallerClass();
> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());

Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?

[^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
[^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.

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

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

From wkemper at openjdk.java.net  Wed May  4 20:44:47 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 4 May 2022 20:44:47 GMT
Subject: Integrated: Have adaptive heuristic include only full cycles in
 average cycle time
In-Reply-To: <dNr6QQanDteXmZNmBlizZot9ThXl7ZqTqGpyPEsZtdQ=.d3b35926-d10a-46b8-9e3f-288c83ba40a3@github.com>
References: <dNr6QQanDteXmZNmBlizZot9ThXl7ZqTqGpyPEsZtdQ=.d3b35926-d10a-46b8-9e3f-288c83ba40a3@github.com>
Message-ID: <2t1ydrhlBzBKJ_NO0pi8NKC9yg0aCah9EwW02V26LYY=.9be64e93-a4a3-4105-8e6c-8a64e5f8829a@github.com>

On Wed, 4 May 2022 15:55:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We have observed cases when a high percentage of short cut cycles (i.e., when evacuation and update reference phases are skipped) may cause the heuristic to believe it can complete _any_ cycle in the time it takes to complete an abbreviated cycle. Triggering the cycle too late may lead to a degenerated cycle. Abbreviated "learning cycles" are similarly ignored. 
> 
> A command line option has been added to disable this change in behavior and restore the previous behavior of including every cycle's time in the average time.

This pull request has now been integrated.

Changeset: 469df3ec
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/469df3ec494e5533cd0141780b47e9a5383c6876
Stats:     29 lines in 10 files changed: 15 ins; 0 del; 14 mod

Have adaptive heuristic include only full cycles in average cycle time

Reviewed-by: zgu

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

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

From mcimadamore at openjdk.java.net  Wed May  4 23:24:29 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:24:29 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
Message-ID: <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>

On Wed, 4 May 2022 16:47:28 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Tweak support for Linker lookup
>>    Improve javadoc of SymbolLookup
>>  - Tweak Addressable javadoc
>>  - Downcall and upcall tests use wrong layout which is missing some trailing padding
>>  - Simplify libraryLookup impl
>>  - Address CSR comments
>>  - Merge branch 'master' into foreign-preview
>>  - Add ValueLayout changes
>>  - Tweak support for array element var handle
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:
> 
>> 151:     static SymbolLookup loaderLookup() {
>> 152:         Class<?> caller = Reflection.getCallerClass();
>> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());
> 
> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?
> 
> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.

Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?

As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).

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

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

From mcimadamore at openjdk.java.net  Wed May  4 23:30:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:30:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v38]
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: <lTPkMd6NbMrGw592RcSdVDv5aZy5f24Akl5N_K1qtyI=.f9b760d0-e5aa-4113-812c-3ff704274704@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 examples in SymbolLookup javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/41d055ab..853f06b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36-37

  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  Wed May  4 23:32:49 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:32:49 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
Message-ID: <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>

On Wed, 4 May 2022 23:20:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:
>> 
>>> 151:     static SymbolLookup loaderLookup() {
>>> 152:         Class<?> caller = Reflection.getCallerClass();
>>> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());
>> 
>> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?
>> 
>> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
>> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.
>
> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?
> 
> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).

Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.

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

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

From mcimadamore at openjdk.java.net  Wed May  4 23:47:30 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:47:30 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
Message-ID: <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>

On Wed, 4 May 2022 23:29:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?
>> 
>> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).
>
> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.

Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.

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

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

From mchung at openjdk.java.net  Thu May  5 16:26:37 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 16:26:37 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
Message-ID: <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>

On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.
>
> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.

`BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).

To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.

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

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

From mchung at openjdk.java.net  Thu May  5 16:42:25 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 16:42:25 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
 <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
Message-ID: <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>

On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.
>
> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).
> 
> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.

When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`.    I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader.  This is consistent with JNI `FindClass` when invoked with no caller frame.

It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class.   However, the existing behavior may likely be unchanged because of the compatibility risk.

[1] https://bugs.openjdk.java.net/browse/JDK-8281001

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

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

From mcimadamore at openjdk.java.net  Thu May  5 20:54:53 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 20:54:53 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
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: <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@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:

  * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
  * Tweak restricted method check to work when there's no caller class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/853f06b8..4d24ffa9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37-38

  Stats: 22 lines in 2 files changed: 16 ins; 1 del; 5 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 May  5 20:54:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 20:54:55 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
 <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
 <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>
Message-ID: <-zAvw8aE9e94OWQyDLUT3IqPzKJFT3v0x_HQVJObonc=.3370a3b7-e797-439f-8a72-ff6d3ec59be4@github.com>

On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).
>> 
>> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.
>
> When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`.    I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader.  This is consistent with JNI `FindClass` when invoked with no caller frame.
> 
> It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class.   However, the existing behavior may likely be unchanged because of the compatibility risk.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8281001

Thanks for the comments. I've pushed a new change which fixes a couple of thing:

* first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!)

* second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check.

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

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

From mchung at openjdk.java.net  Thu May  5 21:34:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 21:34:54 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
Message-ID: <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>

On Thu, 5 May 2022 20:54:53 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:
> 
>   * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>   * Tweak restricted method check to work when there's no caller class

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161:

> 159:                 ClassLoader.getSystemClassLoader();
> 160:         MemorySession loaderSession = (loader == null) ?
> 161:                 MemorySession.global() : // boot loader never goes away

The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded.   Should they use the globel memory session?

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:

> 118:         // if there is no caller class, act as if the call came from an unnamed module
> 119:         Module module = currentClass != null ?
> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;

This can be simplified to:

Module module = currentClass != null ?
               currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();


No need to have the Holder class.

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

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

From mcimadamore at openjdk.java.net  Fri May  6 08:44:18 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 08:44:18 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
 <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
Message-ID: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>

On Thu, 5 May 2022 21:28:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>   * Tweak restricted method check to work when there's no caller class
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161:
> 
>> 159:                 ClassLoader.getSystemClassLoader();
>> 160:         MemorySession loaderSession = (loader == null) ?
>> 161:                 MemorySession.global() : // boot loader never goes away
> 
> The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded.   Should they use the globel memory session?

good idea

> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:
> 
>> 118:         // if there is no caller class, act as if the call came from an unnamed module
>> 119:         Module module = currentClass != null ?
>> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;
> 
> This can be simplified to:
> 
> Module module = currentClass != null ?
>                currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();
> 
> 
> No need to have the Holder class.

gah! I missed that :-)

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

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

From mcimadamore at openjdk.java.net  Fri May  6 11:51:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:51:46 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v40]
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: <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@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 tests for loaderLookup/restricted method corner cases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/4d24ffa9..b71c4e93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38-39

  Stats: 248 lines in 10 files changed: 239 ins; 4 del; 5 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  Fri May  6 11:51:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:51:46 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
 <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
 <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>
Message-ID: <Odtl0HHxQJgJ-iYs-nn7IkIYEv8pSCCh_I-PvT1-__U=.692f3729-cdb6-4eba-9e89-c2caf2fcaf63@github.com>

On Fri, 6 May 2022 08:42:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:
>> 
>>> 118:         // if there is no caller class, act as if the call came from an unnamed module
>>> 119:         Module module = currentClass != null ?
>>> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;
>> 
>> This can be simplified to:
>> 
>> Module module = currentClass != null ?
>>                currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();
>> 
>> 
>> No need to have the Holder class.
>
> gah! I missed that :-)

I've addressed these comments (thanks!) and also added some tests for these corner cases.

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

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

From duke at openjdk.java.net  Fri May  6 16:00:59 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 6 May 2022 16:00:59 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v40]
In-Reply-To: <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@github.com>
Message-ID: <zVq5gxbr2gaHM7fXVDtI9Fih0pZQl9GyREQ4MsbIdYg=.e995c287-2a11-4a88-8284-f8c215c80ca6@github.com>

On Fri, 6 May 2022 11:51:46 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:
> 
>   Add tests for loaderLookup/restricted method corner cases

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 116:

> 114:         // if there is no caller class, act as if the call came from unnamed module of system class loader
> 115:         Module module = currentClass != null ?
> 116:                 currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule();

**Nit:** maybe?add a?line?break
Suggestion:

                currentClass.getModule() :
                ClassLoader.getSystemClassLoader().getUnnamedModule();

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

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

From mcimadamore at openjdk.java.net  Fri May  6 16:48:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 16:48:11 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v41]
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: <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@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:

  Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss 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/b71c4e93..f823bf84

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=40
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39-40

  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 mchung at openjdk.java.net  Fri May  6 16:55:12 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 May 2022 16:55:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v41]
In-Reply-To: <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@github.com>
Message-ID: <0liX9cVSEjplWxVgGoM5rN2JZLqN27jSsNxjbucze_o=.fbc3a8fa-acdf-45f4-a717-0fbaa13760d2@github.com>

On Fri, 6 May 2022 16:48:11 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:
> 
>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by mchung (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Mon May  9 08:26:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 08:26:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v42]
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: <P965vI1xrotIG0xVql0IUcl1rfywCan2ci37LPj56ok=.a9667d42-c7ac-485e-bc01-88637207ec34@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 62 commits:

 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - Tweak Addressable javadoc
 - Downcall and upcall tests use wrong layout which is missing some trailing padding
 - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41
  Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 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 May  9 17:41:10 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 17:41:10 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
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: <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@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 crashes in heap segment benchmarks due to misaligned access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=42
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41-42

  Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 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  Mon May  9 18:17:00 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 9 May 2022 18:17:00 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
In-Reply-To: <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
Message-ID: <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>

On Mon, 9 May 2022 17:41:10 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 crashes in heap segment benchmarks due to misaligned access

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69:

> 67:     static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8);
> 68:     static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8);
> 69:     static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle();

To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`.

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

Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1]

[^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43

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

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

From mcimadamore at openjdk.java.net  Mon May  9 20:30:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 20:30:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
In-Reply-To: <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
 <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>
Message-ID: <Zjv5MbxQTerqGoIscFVqnSaHxjpN82zi8cDGexD74Ng=.7391bdff-3fc3-49d9-ad79-da05ae8d9ce1@github.com>

On Mon, 9 May 2022 18:09:51 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix crashes in heap segment benchmarks due to misaligned access
>
> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69:
> 
>> 67:     static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8);
>> 68:     static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8);
>> 69:     static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle();
> 
> To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`.
> 
> --------------------------------------------------------------------------------
> 
> Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1]
> 
> [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43

I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn.

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

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

From kdnilsen at openjdk.java.net  Tue May 10 23:14:24 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 10 May 2022 23:14:24 GMT
Subject: RFR: Balance without cancel [v2]
In-Reply-To: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
References: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
Message-ID: <AV627DHc3T8QDaWkNpR55geXeh0LcDkoCCkw_YXyv48=.6b9430d5-bdd0-427d-9746-497ba47ac667@github.com>

> This commit does load balancing on remembered set scanning that happens during concurrent marking and during concurrent updating of references.  Experiments show that the concurrency of remembered set marking is now much closer to the number of concurrent GC threads (generally within 5%) whereas before this commit, the level of concurrency was often less than 1/4 of the number of concurrent GC threads.
> 
> An additional fix integrated in this commit is to not scan the entirety of humongous object arrays.  We only scan the portions of these arrays that overlay with dirty cards in the remembered set.

Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:

 - Enhance logging information
 - Do not use shared allocation for promotions smaller than PLAB::min_size

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/136/files
  - new: https://git.openjdk.java.net/shenandoah/pull/136/files/98be07c7..b249a2c5

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

  Stats: 103 lines in 5 files changed: 95 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/136/head:pull/136

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

From wkemper at openjdk.java.net  Tue May 10 23:30:50 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 10 May 2022 23:30:50 GMT
Subject: RFR: Filter out invalid pointers picked up by old gen SATB
Message-ID: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>

In some cases, the SATB barrier used to support old generation marking may capture a reference to an object that is later evacuated. Old gen marking will crash when it tries to mark through the reference.

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

Commit messages:
 - Filter out invalid pointers picked up by old gen SATB

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

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

From mcimadamore at openjdk.java.net  Wed May 11 10:39:44 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 11 May 2022 10:39:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v44]
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: <nYEfBb0y4TtQ3webD87xAB7Hdwwdb1n0sY6Ff2Mfl0U=.e640ddd8-bee5-4a91-9277-06ac0ccf0993@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 64 commits:

 - Merge branch 'master' into foreign-preview
 - Fix crashes in heap segment benchmarks due to misaligned access
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - ... and 54 more: https://git.openjdk.java.net/jdk/compare/73c5e993...cdd006e7

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=43
  Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 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 wkemper at openjdk.java.net  Wed May 11 22:05:21 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 11 May 2022 22:05:21 GMT
Subject: RFR: Filter out invalid pointers picked up by old gen SATB [v2]
In-Reply-To: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>
References: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>
Message-ID: <metYbFUwP4_He4sJM8WI_NLOOJEi-bhkvhUqjI1ELUI=.f5fa069b-7c03-4d06-8db5-f1cdebb7afc6@github.com>

> In some cases, the SATB barrier used to support old generation marking may capture a reference to an object that is later evacuated. Old gen marking will crash when it tries to mark through the reference.

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Purge SATB in final update refs, rather than SATB filter
 - Revert "Filter out invalid pointers picked up by old gen SATB"
   
   This reverts commit e1fa77a65aa72d7cd22732bb95b73af950b589b1.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/140/files
  - new: https://git.openjdk.java.net/shenandoah/pull/140/files/e1fa77a6..9cf5b711

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

  Stats: 34 lines in 2 files changed: 18 ins; 15 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/140.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/140/head:pull/140

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

From kdnilsen at openjdk.java.net  Thu May 12 15:12:00 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 12 May 2022 15:12:00 GMT
Subject: RFR: Filter out invalid pointers picked up by old gen SATB [v2]
In-Reply-To: <metYbFUwP4_He4sJM8WI_NLOOJEi-bhkvhUqjI1ELUI=.f5fa069b-7c03-4d06-8db5-f1cdebb7afc6@github.com>
References: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>
 <metYbFUwP4_He4sJM8WI_NLOOJEi-bhkvhUqjI1ELUI=.f5fa069b-7c03-4d06-8db5-f1cdebb7afc6@github.com>
Message-ID: <ziEgL3q5TL4_7Yzm1v86LCDk19irr4BwNsiQchy82rw=.b01dfdb1-b651-4180-aa6b-dc324e35cd0f@github.com>

On Wed, 11 May 2022 22:05:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> In some cases, the SATB barrier used to support old generation marking may capture a reference to an object that is later evacuated. Old gen marking will crash when it tries to mark through the reference.
>
> William Kemper has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Purge SATB in final update refs, rather than SATB filter
>  - Revert "Filter out invalid pointers picked up by old gen SATB"
>    
>    This reverts commit e1fa77a65aa72d7cd22732bb95b73af950b589b1.

Marked as reviewed by kdnilsen (Committer).

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

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

From mcimadamore at openjdk.java.net  Thu May 12 15:45:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 15:45:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
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: <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@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 65 commits:

 - Merge branch 'master' into foreign-preview
 - Merge branch 'master' into foreign-preview
 - Fix crashes in heap segment benchmarks due to misaligned access
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=44
  Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 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 May 12 15:51:00 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 15:51:00 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <HVsG_LCCzlUo1f-0ZMKlCGM047qK2h9Klo3NGEPhfaM=.5717ef82-7868-43e7-bb12-9f64c434455c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
 <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>
 <ev2fhY31U-E7cbjQ1P6z8ZpvNwM3u6gA0QtxsxtLSfI=.aec946ee-f52e-463e-af90-5d9778fd8492@github.com>
 <HVsG_LCCzlUo1f-0ZMKlCGM047qK2h9Klo3NGEPhfaM=.5717ef82-7868-43e7-bb12-9f64c434455c@github.com>
Message-ID: <dbFLtJZfh6yqYSbmciA1EVBS9tmIsO01dlNafDuNanE=.25a875db-8dc9-4152-8f40-028830bd85d3@github.com>

On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>>> Remind: please use the command `/jep JEP-424` [1] to mark this PR.
>>> 
>>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep
>> 
>> Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR?
>
>> would a jep unneeded be enough to "unstuck" this PR?
> 
> Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command.

@lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do?

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

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

From wkemper at openjdk.java.net  Thu May 12 16:17:37 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 12 May 2022 16:17:37 GMT
Subject: Integrated: Filter out invalid pointers picked up by old gen SATB
In-Reply-To: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>
References: <D5EcFdNjKVi9WMOSjntcWCFaAao4cmB9PqXkyvPgcK8=.8cf6e8b1-0eaa-4577-be07-20acd92c05c1@github.com>
Message-ID: <AAnaJeYZIAQ_7tSmQQTfjZxoaFVxrgSf2su7n0D9wQI=.d9f3e494-2a3e-400d-85f0-e648877f8ebf@github.com>

On Tue, 10 May 2022 23:24:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In some cases, the SATB barrier used to support old generation marking may capture a reference to an object that is later evacuated. Old gen marking will crash when it tries to mark through the reference.

This pull request has now been integrated.

Changeset: 58ea1065
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/58ea1065304aaf45d51069a2e0ee7a3e71007677
Stats:     18 lines in 1 file changed: 18 ins; 0 del; 0 mod

Filter out invalid pointers picked up by old gen SATB

Reviewed-by: kdnilsen

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

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

From mcimadamore at openjdk.java.net  Thu May 12 16:21:59 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 16:21:59 GMT
Subject: Integrated: 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: <hmpin9Cqva6tkM3JCE4g2H_bPeBpyN3zQVylTihD-bo=.474bbfb3-127a-44de-b6e0-a5b90729f395@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

This pull request has now been integrated.

Changeset: 2c5d1362
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7
Stats:     65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod

8282191: Implementation of Foreign Function & Memory API (Preview)

Reviewed-by: erikj, jvernee, psandoz, dholmes, mchung

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

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

From jiefu at openjdk.java.net  Fri May 13 02:54:23 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 02:54:23 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case of
 GCCause::_codecache_GC_threshold
Message-ID: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>

Hi all,

Some tests fail with Shenandoah GC after JDK-8282191.
The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
It would be better to fix it.

Thanks.
Best regards,
Jie

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

Commit messages:
 - ShenandoahControlThread::request_gc misses the case of GCCause::_codecache_GC_threshold

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

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

From alanb at openjdk.java.net  Fri May 13 06:39:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 06:39:49 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

test/jdk/java/foreign/TestIntrinsics.java line 48:

> 46:  *   -XX:+UseShenandoahGC
> 47:  *   TestIntrinsics
> 48:  */

Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.

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

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

From jiefu at openjdk.java.net  Fri May 13 06:50:52 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 06:50:52 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
Message-ID: <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>

On Fri, 13 May 2022 06:36:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> Some tests fail with Shenandoah GC after JDK-8282191.
>> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
>> It would be better to fix it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> test/jdk/java/foreign/TestIntrinsics.java line 48:
> 
>> 46:  *   -XX:+UseShenandoahGC
>> 47:  *   TestIntrinsics
>> 48:  */
> 
> Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.

Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.

What do you mean by `if you are testing with +ShenandoahGC then it will run already`?

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

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

From alanb at openjdk.java.net  Fri May 13 06:59:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 06:59:48 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
Message-ID: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>

On Fri, 13 May 2022 06:47:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/jdk/java/foreign/TestIntrinsics.java line 48:
>> 
>>> 46:  *   -XX:+UseShenandoahGC
>>> 47:  *   TestIntrinsics
>>> 48:  */
>> 
>> Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.
>
> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
> 
> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?

I assume you are running the tests with:
   make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
in which case, all of the tests you select to run will be run with that GC. 

What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

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

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

From jiefu at openjdk.java.net  Fri May 13 07:16:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 07:16:39 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <Z0abpxhHnkgX9PqihMQobLhB6nXLfjXDo1B1Xbamgvg=.30a1aa6c-0bd8-4fc4-aa76-a5b3bc79cdae@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you are running the tests with: make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" in which case, all of the tests you select to run will be run with that GC.

Yes, you're right.

> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

I would suggest reusing the existing test in java/foreign.
This is because this bug was first triggered after `Implementation of Foreign Function & Memory API (Preview)` integration.
And I don't want a copy-paste code duplication in a new test file.
Thanks.

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

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

From uschindler at openjdk.java.net  Fri May 13 08:37:18 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 08:37:18 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
Message-ID: <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>

On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Merge branch 'master' into foreign-preview
>>  - Fix crashes in heap segment benchmarks due to misaligned access
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Add tests for loaderLookup/restricted method corner cases
>>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>    * Tweak restricted method check to work when there's no caller class
>>  - Tweak examples in SymbolLookup javadoc
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:
> 
>> 1043:      *
>> 1044:      * @throws UnsupportedOperationException
>> 1045:      *         If an unsupported map mode is specified.
> 
> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.
> 
> As this is already merged, should I open a PR fixing the docs or open an issue?

This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)

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

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

From uschindler at openjdk.java.net  Fri May 13 08:37:17 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 08:37:17 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
Message-ID: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>

On Thu, 12 May 2022 15:45:01 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 65 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Merge branch 'master' into foreign-preview
>  - Fix crashes in heap segment benchmarks due to misaligned access
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Add tests for loaderLookup/restricted method corner cases
>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>    * Tweak restricted method check to work when there's no caller class
>  - Tweak examples in SymbolLookup javadoc
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b

Some late comments and suggestions to fix inconsistencies and wrong javadocs.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:

> 1043:      *
> 1044:      * @throws UnsupportedOperationException
> 1045:      *         If an unsupported map mode is specified.

I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.

As this is already merged, should I open a PR fixing the docs or open an issue?

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:

> 1162:         }
> 1163:         if (unmapper != null) {
> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,

When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
- New code returning `MemorySegment` uses `unmapper.address()`
- Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)

Should I open an issue or a PR to fix this (because this is already merged)?

See the mailing list posts:
- https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
- https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html

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

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

From mcimadamore at openjdk.java.net  Fri May 13 09:48:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:48:02 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
Message-ID: <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>

On Fri, 13 May 2022 08:33:11 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:
>> 
>>> 1043:      *
>>> 1044:      * @throws UnsupportedOperationException
>>> 1045:      *         If an unsupported map mode is specified.
>> 
>> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.
>> 
>> As this is already merged, should I open a PR fixing the docs or open an issue?
>
> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)

@uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue.

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

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

From mcimadamore at openjdk.java.net  Fri May 13 09:48:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:48:08 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
Message-ID: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>

On Fri, 13 May 2022 08:29:13 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Merge branch 'master' into foreign-preview
>>  - Fix crashes in heap segment benchmarks due to misaligned access
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Add tests for loaderLookup/restricted method corner cases
>>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>    * Tweak restricted method check to work when there's no caller class
>>  - Tweak examples in SymbolLookup javadoc
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:
> 
>> 1162:         }
>> 1163:         if (unmapper != null) {
>> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,
> 
> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
> - New code returning `MemorySegment` uses `unmapper.address()`
> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)
> 
> Should I open an issue or a PR to fix this (because this is already merged)?
> 
> See the mailing list posts:
> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html

Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code.

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

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

From uschindler at openjdk.java.net  Fri May 13 11:06:12 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 11:06:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
Message-ID: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>

On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:
>> 
>>> 1162:         }
>>> 1163:         if (unmapper != null) {
>>> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,
>> 
>> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
>> - New code returning `MemorySegment` uses `unmapper.address()`
>> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)
>> 
>> Should I open an issue or a PR to fix this (because this is already merged)?
>> 
>> See the mailing list posts:
>> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
>> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html
>
> Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code.

RFE = issue?

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

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

From mcimadamore at openjdk.java.net  Fri May 13 12:03:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:03:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
 <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
Message-ID: <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>

On Fri, 13 May 2022 11:01:09 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> RFE = issue?

issue, with type RFE (request for enhancement)

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

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

From uschindler at openjdk.java.net  Fri May 13 12:19:15 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 12:19:15 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
 <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
 <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>
Message-ID: <DwOTD2DJi_QMv7B0AEkLYGu-QGHhfrwveJtckt9Y_CU=.68ac1153-12aa-4bdf-b5f4-1ed9f09af790@github.com>

On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> RFE = issue?
>
>> RFE = issue?
> 
> issue, with type RFE (request for enhancement)

See: https://bugs.openjdk.java.net/browse/JDK-8286734

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

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

From uschindler at openjdk.java.net  Fri May 13 12:29:09 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 12:29:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
 <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>
Message-ID: <_qJfbHWbWDSXgHQx9PRP2YDQ7cLkC41BmxL_osQIRhs=.dd01fb6e-e671-4bb4-8332-9c9d337abaf9@github.com>

On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)
>
> @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue.

See https://bugs.openjdk.java.net/browse/JDK-8286735

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

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

From zgu at openjdk.java.net  Fri May 13 12:30:03 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 13 May 2022 12:30:03 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

LGTM

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

Marked as reviewed by zgu (Reviewer).

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

From mcimadamore at openjdk.java.net  Fri May 13 12:47:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:47:38 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <e4z5TOmcqmZ9NVTAkksVWVqamxv3_HFl2zNMe0OIl9Y=.af70855b-3c51-4490-baa1-a2df33d85d8f@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
>> 
>> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?
>
> I assume you are running the tests with:
>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
> in which case, all of the tests you select to run will be run with that GC. 
> 
> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.

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

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

From jiefu at openjdk.java.net  Fri May 13 13:04:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:04:54 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
>> 
>> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?
>
> I assume you are running the tests with:
>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
> in which case, all of the tests you select to run will be run with that GC. 
> 
> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.

I think it's a waste of time to write a separate test for this bug.

I can't understand why you are against adding one more test config in the foreign test.
Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
If you are still against the newly added test config, I can revert the test change.
Thanks.

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

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

From dholmes at openjdk.java.net  Fri May 13 13:22:03 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 13 May 2022 13:22:03 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
 <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
Message-ID: <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>

On Fri, 13 May 2022 13:02:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> I assume you are running the tests with:
>>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
>> in which case, all of the tests you select to run will be run with that GC. 
>> 
>> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?
>
>> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.
> 
> I think it's a waste of time to write a separate test for this bug.
> 
> I can't understand why you are against adding one more test config in the foreign test.
> Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
> If you are still against the newly added test config, I can revert the test change.
> Thanks.

My comment seems to have never made it through. The problem with what your are doing is two-fold:
1. When running the test suite specifically to test xGC for whatever x you are now forcing a test run for Shenandoah.
2.  When x is Shenandoah then you run this test twice.

You don't need a config just to run this with Shenandoah - you run the test suite with Shenandoah.

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

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

From jiefu at openjdk.java.net  Fri May 13 13:48:43 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:48:43 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <2yg0dzjun8djDothlefQppcbc72bruuLiM6T_5y-WDw=.3acc77a0-2b39-4afb-8c80-b823dfc83f86@github.com>

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Revert the test change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8691/files
  - new: https://git.openjdk.java.net/jdk/pull/8691/files/8f094d32..dc96246c

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

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

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

From jiefu at openjdk.java.net  Fri May 13 13:48:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:48:44 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
 <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
 <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>
Message-ID: <oZphkb9JhnvZQEGRsDybsPaiInE6d8RQPi_4LhilZWM=.a718bcd0-f0a7-462a-818a-bc153e2f92b3@github.com>

On Fri, 13 May 2022 13:18:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.
>> 
>> I think it's a waste of time to write a separate test for this bug.
>> 
>> I can't understand why you are against adding one more test config in the foreign test.
>> Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
>> If you are still against the newly added test config, I can revert the test change.
>> Thanks.
>
> My comment seems to have never made it through. The problem with what your are doing is two-fold:
> 1. When running the test suite specifically to test xGC for whatever x you are now forcing a test run for Shenandoah.
> 2.  When x is Shenandoah then you run this test twice.
> 
> You don't need a config just to run this with Shenandoah - you run the test suite with Shenandoah.

The test change had been reverted.
Thanks.

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

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

From jiefu at openjdk.java.net  Sat May 14 10:17:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 14 May 2022 10:17:39 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>
Message-ID: <qAYsYTds6x8Cz1Yp2xoBevJiBpuiMRWDVnFnlHgBdv8=.6497fa79-d4f6-433c-9ca0-718daf012005@github.com>

On Fri, 13 May 2022 12:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> LGTM

Thanks @zhengyu123 for the review.

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

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

From jiefu at openjdk.java.net  Sat May 14 10:17:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 14 May 2022 10:17:39 GMT
Subject: Integrated: 8286681: ShenandoahControlThread::request_gc misses the
 case of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <7FhFBw0mS9iLpQbgQGHhwo8EItF2WysYc7mivFnM06k=.191dc815-f675-4840-a4fb-1cb94a36d0b4@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 9eb15c9b
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9eb15c9b100b87e332c572bbc24a818e1cceb180
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8286681: ShenandoahControlThread::request_gc misses the case of GCCause::_codecache_GC_threshold

Reviewed-by: zgu

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

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

From zgu at openjdk.java.net  Tue May 17 19:10:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 17 May 2022 19:10:42 GMT
Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed with
 Loom
Message-ID: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>

Please review this patch that fixed failed tests.

To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase.

Test:

- [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 
- [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64

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

Commit messages:
 - Add comments
 - v0

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

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

From shade at openjdk.java.net  Wed May 18 06:25:59 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 18 May 2022 06:25:59 GMT
Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed
 with Loom
In-Reply-To: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
References: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
Message-ID: <UFRH8jvGHd4rDd3nu82rjGFuQM5RqiGu70IuI5hUg-k=.b552457f-b6e2-45a7-8ab3-e473dde4a0ca@github.com>

On Tue, 17 May 2022 19:02:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch that fixed failed tests.
> 
> To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase.
> 
> Test:
> 
> - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 
> - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64
> - [ ] GHA

Looks fine.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2318:

> 2316:     return false;
> 2317:   }
> 2318:   // Objects allocated after evacuation start are guaranteed in to-space, don't need any barriers

Newline missing between these two, I think.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Wed May 18 12:34:54 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 18 May 2022 12:34:54 GMT
Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed
 with Loom [v2]
In-Reply-To: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
References: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
Message-ID: <Y8kohhmyHicEW4mtIFq7FmQBvSPSPDRCY9Otlb8_pOg=.583f667b-2838-4032-bb17-c9b73b97c02d@github.com>

> Please review this patch that fixed failed tests.
> 
> To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase.
> 
> Test:
> 
> - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 
> - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64
> - [ ] GHA

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Added space line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8757/files
  - new: https://git.openjdk.java.net/jdk/pull/8757/files/c565201f..69c24158

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

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

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

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
Message-ID: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

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

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

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

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

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <DOokHH_SxPtXjdpCSV9F_RmnHaNC6WnO3ChzhQNGxF8=.3fbb1072-bae7-4dc9-a424-4e9dd0cecc33@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

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

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

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AIjhEfuQaJLjZPeDl94HgUet9eMCoEwolZpNvKGGHGs=.bb1c32b4-65d8-40f2-84c3-38dc7db54894@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

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

Marked as reviewed by wetmore (Reviewer).

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

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

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

Marked as reviewed by naoto (Reviewer).

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

From wkemper at openjdk.java.net  Wed May 18 16:31:44 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 18 May 2022 16:31:44 GMT
Subject: RFR: Start young collect instead of old if mixed evacuations are
 pending
Message-ID: <5J9IeshiStjdvNUB5e-ilhoWnF1gvyduMtuPgu7JrV8=.d7560478-ef1b-46d7-985f-750eef4bb261@github.com>

This change addresses a race condition in which the heuristic could start an old gc while there are pending mixed evacuations. This condition could lead to a crash because the nascent old gen collect will clear the mark bitmap, but the remembered set scan of the bootstrap collection will use the mark bitmap to find objects if it believes mixed evacuations are in progress.

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

Commit messages:
 - Start young collect instead of old if mixed evacuations are pending

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

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

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <pRvaphDcC8dB1bZPh6x4OhyZ8BHSfCn9ZCdBzq9Dnco=.1ca1edd4-0004-43b9-815c-3b20ffb5368f@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

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

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

From kdnilsen at openjdk.java.net  Wed May 18 17:45:19 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 18 May 2022 17:45:19 GMT
Subject: RFR: Start young collect instead of old if mixed evacuations are
 pending
In-Reply-To: <5J9IeshiStjdvNUB5e-ilhoWnF1gvyduMtuPgu7JrV8=.d7560478-ef1b-46d7-985f-750eef4bb261@github.com>
References: <5J9IeshiStjdvNUB5e-ilhoWnF1gvyduMtuPgu7JrV8=.d7560478-ef1b-46d7-985f-750eef4bb261@github.com>
Message-ID: <vWSClb5B_PqXTzIVteezB1OXqtwTIzaczKCoER2lzcc=.4e3ae37f-3920-4bc7-b2a0-f4a5a9935c92@github.com>

On Wed, 18 May 2022 16:24:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change addresses a race condition in which the heuristic could start an old gc while there are pending mixed evacuations. This condition could lead to a crash because the nascent old gen collect will clear the mark bitmap, but the remembered set scan of the bootstrap collection will use the mark bitmap to find objects if it believes mixed evacuations are in progress.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Wed May 18 17:56:22 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 18 May 2022 17:56:22 GMT
Subject: Integrated: Start young collect instead of old if mixed evacuations
 are pending
In-Reply-To: <5J9IeshiStjdvNUB5e-ilhoWnF1gvyduMtuPgu7JrV8=.d7560478-ef1b-46d7-985f-750eef4bb261@github.com>
References: <5J9IeshiStjdvNUB5e-ilhoWnF1gvyduMtuPgu7JrV8=.d7560478-ef1b-46d7-985f-750eef4bb261@github.com>
Message-ID: <bAXEJZ-RQHHp3zzCdAU8xhmhKi38BGP5lsviVwyH0yU=.bb57792c-3105-4541-b06e-b4e3b0ff7ce1@github.com>

On Wed, 18 May 2022 16:24:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change addresses a race condition in which the heuristic could start an old gc while there are pending mixed evacuations. This condition could lead to a crash because the nascent old gen collect will clear the mark bitmap, but the remembered set scan of the bootstrap collection will use the mark bitmap to find objects if it believes mixed evacuations are in progress.

This pull request has now been integrated.

Changeset: 5473b079
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/5473b0791974077e47ebad400e537b7f5e920912
Stats:     12 lines in 2 files changed: 11 ins; 1 del; 0 mod

Start young collect instead of old if mixed evacuations are pending

Reviewed-by: kdnilsen

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

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

From zgu at openjdk.java.net  Wed May 18 18:30:41 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 18 May 2022 18:30:41 GMT
Subject: Integrated: 8286814: Shenandoah: RedefineRunningMethods.java test
 failed with Loom
In-Reply-To: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
References: <vzkE9Wh0cXH2ebf1y76EOolgDMToAiePnODdXMuIu-k=.e445029c-bc7d-4d72-8c2e-99e11b075174@github.com>
Message-ID: <HQi6cocrBHRiPeu257UQKhmqB0BqGGbObwIADtwZ_ys=.c0a4e440-2404-4ef5-a1ac-fdf41478288e@github.com>

On Tue, 17 May 2022 19:02:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch that fixed failed tests.
> 
> To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase.
> 
> Test:
> 
> - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 
> - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64
> - [ ] GHA

This pull request has now been integrated.

Changeset: cd5bfe7b
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd5bfe7b97d581a7c7fdb39df72bb22bfaed4f50
Stats:     18 lines in 2 files changed: 10 ins; 0 del; 8 mod

8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom

Reviewed-by: shade

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

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

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <c0o1YvhNkDe026TrcGqKdFaH6G93AfyQCHvBLzGNf8s=.007721e9-d02c-4319-a562-c3296fed6bbf@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

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

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

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

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

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

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <gSIQ2U9H0PmGgCBlsc4SocQff7AauSX3jiC10z26SJQ=.af26181b-5c61-4ecc-b836-5e5cff2cc901@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

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

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

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <A3yxKJkrz3h716ciAsbQHtiWg_y5gMtqLrMoDSxFTWE=.6e31ca1c-505c-4794-b1f0-622dc811388c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

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

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

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

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

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

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

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

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

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

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

Marked as reviewed by kevinw (Committer).

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

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AEcXIgzPrzjMIYqVKaZBv2j_3w8nrjL-kejrZ0nvBGE=.cb7c63c7-8f32-4cfa-b7d5-e2bb84750add@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

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

Marked as reviewed by xuelei (Reviewer).

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

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: <lPlIgFLf96r_Xr7YJIr2w2uODPCG9bRPhAnl2tuAo50=.82a145da-9923-4c5b-a72d-14ba982bf303@github.com>

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

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

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

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <De1XJE92ZHSiL99Rs-yvnD30-uzxuj4sfIn432JAocM=.2d3d0f7a-8c35-4575-aa20-1ccc267021c4@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

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

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

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

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
Message-ID: <bBFati7RKtrl5FcrKP4_YCSO34DZrrIX7b_Daw9f91E=.dbbf28d9-92ef-4ae1-950c-f34036d483e4@github.com>

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

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

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

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
Message-ID: <Hm4DXlPz0QuS87RjrcFEwxyh-97burW3YzckN3z0aGM=.6c816cc2-3256-4b2c-87d7-c2206b9f9a39@github.com>

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

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

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

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v3]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

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

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

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

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and
 java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ZIBUrN38HimpUwfEYc-LwYC3gXjfDXNaD55bHE9PU2M=.87e99c4b-c1a3-47d4-9323-421efb88ed06@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

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

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

From zgu at openjdk.java.net  Fri May 27 23:21:57 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 27 May 2022 23:21:57 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support
Message-ID: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>

Please review the patch that fixes Loom support in Shenandoah GC.

- stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
- During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
- Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.

Test:  
- [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
- [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
- [x] hotspot_gc_shenandoah  on Linux x86_32
- [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
- [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)

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

Commit messages:
 - Fix comment
 - Fix comment
 - Cleanup
 - Fix
 - Simplify
 - Fix requires_barriers
 - fix
 - Fix stw mark
 - cleanup and update copyright years
 - cleanup
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/6cc4bb11...7db9c0b8

Changes: https://git.openjdk.java.net/jdk/pull/8924/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286829
  Stats: 110 lines in 14 files changed: 75 ins; 7 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8924.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8924/head:pull/8924

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

From shade at openjdk.java.net  Mon May 30 07:13:44 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 May 2022 07:13:44 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support
In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
Message-ID: <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>

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

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

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 529:

> 527:   heap->set_concurrent_mark_in_progress(true);
> 528: 
> 529:   _mark.start_mark();

Style: call `start_mark()` here maybe? Matches the use of `end_mark()` elsewhere.

src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:

> 71:     if (obj->is_instance()) {
> 72:       // Case 1: Normal oop, process as usual.
> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {

Ooof, this is very hot code path. Is there any way to do this without injecting the code here?

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

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

From zgu at openjdk.java.net  Tue May 31 13:18:29 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 31 May 2022 13:18:29 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v2]
In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
Message-ID: <mojjeRS5Z8SCaKNbVfpY6Lv5CG13C9cxD-H0fD6kHdg=.714ab4be-29e6-429a-adee-b00207af75ea@github.com>

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

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Aleksey's comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8924/files
  - new: https://git.openjdk.java.net/jdk/pull/8924/files/7db9c0b8..b86b51b1

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

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

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

From zgu at openjdk.java.net  Tue May 31 13:18:30 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 31 May 2022 13:18:30 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v2]
In-Reply-To: <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
Message-ID: <JaLoowPMXfA99YesKPYkgunnK_sRWdzDLbMQ_SVlMXE=.07fe86f7-63c6-4122-96e0-cff5808ea140@github.com>

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

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey's comment
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 529:
> 
>> 527:   heap->set_concurrent_mark_in_progress(true);
>> 528: 
>> 529:   _mark.start_mark();
> 
> Style: call `start_mark()` here maybe? Matches the use of `end_mark()` elsewhere.

Okay. I am award of asymmetry, but not sure this is better.

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

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

From zgu at openjdk.java.net  Tue May 31 17:45:34 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 31 May 2022 17:45:34 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
Message-ID: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>

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

Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:

 - Fix
 - NMethod::heal_nmethod() does not need to handle ref-update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8924/files
  - new: https://git.openjdk.java.net/jdk/pull/8924/files/b86b51b1..ed84a9e6

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

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

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