Re: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v3]
On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Introduce buildSharedLibraryName Hi Chris and Serguei, thanks for the reviews ! I adjusted the COPYRIGHT years. - PR Comment: https://git.openjdk.org/jdk/pull/15151#issuecomment-1672693986
Re: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v4]
> There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT headers - Changes: - all: https://git.openjdk.org/jdk/pull/15151/files - new: https://git.openjdk.org/jdk/pull/15151/files/9f9c5b25..5e8dfa79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=02-03 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151
Integrated: JDK-8313670: Simplify shared lib name handling code in some tests
On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. This pull request has now been integrated. Changeset: 6dba2026 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/6dba2026d72de6a67aa0209749ded8174b088904 Stats: 130 lines in 9 files changed: 22 ins; 87 del; 21 mod 8313670: Simplify shared lib name handling code in some tests Reviewed-by: cjplummer, sspitsyn - PR: https://git.openjdk.org/jdk/pull/15151
Re: RFR: JDK-8313670: Simplify shared lib name handling code in some tests [v4]
On Thu, 10 Aug 2023 07:44:58 GMT, Matthias Baesken wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust COPYRIGHT headers A belated thumbs up from me too. Thanks. - PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1571269550
Re: RFR: 8298095: Refine implSpec for SegmentAllocator [v5]
> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate > methods as well as clarifying the docs a bit more. Also, a local variable is > renamed. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Simplify java snippets - Changes: - all: https://git.openjdk.org/jdk/pull/14997/files - new: https://git.openjdk.org/jdk/pull/14997/files/c7544307..f0f80b85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=03-04 Stats: 14 lines in 1 file changed: 0 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997 PR: https://git.openjdk.org/jdk/pull/14997
Integrated: 8298095: Refine implSpec for SegmentAllocator
On Mon, 24 Jul 2023 12:32:59 GMT, Per Minborg wrote: > This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate > methods as well as clarifying the docs a bit more. Also, a local variable is > renamed. This pull request has now been integrated. Changeset: 35b60f92 Author:Per Minborg URL: https://git.openjdk.org/jdk/commit/35b60f925a4e7e2e3f1ec7c5c1eee60206e7508a Stats: 249 lines in 1 file changed: 147 ins; 21 del; 81 mod 8298095: Refine implSpec for SegmentAllocator Reviewed-by: mcimadamore - PR: https://git.openjdk.org/jdk/pull/14997
RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows when run as user with Administrator privileges
On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible. - Commit messages: - JDK-8314094 Changes: https://git.openjdk.org/jdk/pull/15222/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15222&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314094 Stats: 21 lines in 1 file changed: 14 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15222.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15222/head:pull/15222 PR: https://git.openjdk.org/jdk/pull/15222
RFR: 8314025: Remove JUnit-based test in java/lang/invoke from problem list
Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development. - Commit messages: - Update ProblemList.txt Changes: https://git.openjdk.org/jdk/pull/15206/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15206&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314025 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15206.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15206/head:pull/15206 PR: https://git.openjdk.org/jdk/pull/15206
Re: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from problem list
On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein wrote: > Please review this change to remove Unit-based tests in `java/lang/invoke` > from `jdk`'s problem list. The underlying race condition in jtreg was fixed > in release 7.3; which is now the default version used in JDK mainline > development. Hello Christian, I think this PR should also be linked against the problem listed JBS issue https://bugs.openjdk.org/browse/JDK-8312482 so that when this is integrated that issue gets resolved. - PR Comment: https://git.openjdk.org/jdk/pull/15206#issuecomment-1672989075
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Thu, 10 Aug 2023 11:13:12 GMT, Raffaello Giulietti wrote: > AFAIK, if you need reproducible randoms in tests, you should add the tags: > > ``` > * @key randomness > * @library /test/lib > ``` > > and initialize your random generator with > > ``` > import jdk.test.lib.RandomFactory; > ... > Random rnd = RandomFactory.getRandom(); > ``` > > This prints the seed to STDOUT. It'd be applicable for tests, but not for benchmarks. Also, the point that @cl4es seems to make is that randomness is captured and set up to reduce noise, not to be able to reproduce "benchmark failures". - PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289976177
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Thu, 10 Aug 2023 11:23:02 GMT, Pavel Rappo wrote: >> AFAIK, if you need reproducible randoms in tests, you should add the tags: >> >> * @key randomness >> * @library /test/lib >> >> and initialize your random generator with >> >> import jdk.test.lib.RandomFactory; >> ... >> Random rnd = RandomFactory.getRandom(); >> >> This prints the seed to STDOUT. > >> AFAIK, if you need reproducible randoms in tests, you should add the tags: >> >> ``` >> * @key randomness >> * @library /test/lib >> ``` >> >> and initialize your random generator with >> >> ``` >> import jdk.test.lib.RandomFactory; >> ... >> Random rnd = RandomFactory.getRandom(); >> ``` >> >> This prints the seed to STDOUT. > > It'd be applicable for tests, but not for benchmarks. Also, the point that > @cl4es seems to make is that randomness is captured and set up to reduce > noise, not to be able to reproduce "benchmark failures". My bad. Forget my note - PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289981733
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Wed, 9 Aug 2023 22:36:47 GMT, Claes Redestad wrote: >> Pavel Rappo has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 13 additional >> commits since the last revision: >> >> - Fix bugs in Shared.createSingle >> - Merge branch 'master' into 8310813 >> - Group params coarser (suggested by @cl4es) >> >>- Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge. >> Every testXYZ method invokes M operations, where M is the maximum >> number of elements in a group. Shorter groups are cyclically padded. >>- Uses the org.openjdk.jmh.infra.Blackhole API and increases >> benchmark time. >>- Fixes a bug in Shared that precluded 0 from being in a pair. >> - Use better overloads (suggested by @cl4es) >> >>- Uses simpler, more suitable overloads for the subrange >> starting from 0 >> - Improve benchmarks >> - Merge branch 'master' into 8310813 >> - Restore hash code values >> >>BigInteger is old and ubiquitous enough so that there might be >>inadvertent dependencies on its hash code. >> >>This commit also includes a test, to make sure hash code is >>unchanged. >> - Merge branch 'master' into 8310813 >> - Add a benchmark >> - Merge branch 'master' into 8310813 >> - ... and 3 more: https://git.openjdk.org/jdk/compare/3425a24d...6fa3f694 > > test/micro/org/openjdk/bench/java/math/Shared.java line 82: > >> 80: } >> 81: int nBytes = (nBits + 7) / 8; >> 82: var r = new Random(); > > Some have a preference for providing a seed for `Random` instances in micros. > Either hard-coded or through a `@Param` (I find this a bit excessive). Doing > so might reduce run-to-run noise. AFAIK, if you need reproducible randoms in tests, you should add the tags: * @key randomness * @library /test/lib and initialize your random generator with import jdk.test.lib.RandomFactory; ... Random rnd = RandomFactory.getRandom(); This prints the seed to STDOUT. - PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289966641
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify >> equals, hashCode, and compareTo for BigInteger. If you have any performance >> concerns, please raise them. >> >> This PR is cherry-picked from a bigger, not-yet-published PR, to test the >> waters. That latter PR will be published soon. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 13 additional > commits since the last revision: > > - Fix bugs in Shared.createSingle > - Merge branch 'master' into 8310813 > - Group params coarser (suggested by @cl4es) > >- Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge. > Every testXYZ method invokes M operations, where M is the maximum > number of elements in a group. Shorter groups are cyclically padded. >- Uses the org.openjdk.jmh.infra.Blackhole API and increases > benchmark time. >- Fixes a bug in Shared that precluded 0 from being in a pair. > - Use better overloads (suggested by @cl4es) > >- Uses simpler, more suitable overloads for the subrange > starting from 0 > - Improve benchmarks > - Merge branch 'master' into 8310813 > - Restore hash code values > >BigInteger is old and ubiquitous enough so that there might be >inadvertent dependencies on its hash code. > >This commit also includes a test, to make sure hash code is >unchanged. > - Merge branch 'master' into 8310813 > - Add a benchmark > - Merge branch 'master' into 8310813 > - ... and 3 more: https://git.openjdk.org/jdk/compare/16b32b66...6fa3f694 Here's a status update for this PR. I'm currently benchmarking baseline against this PR and this PR plus changes in https://github.com/openjdk/jdk/pull/15197. It's a 3-way benchmark, so to speak. Its purpose is to see whether performance degradation brought by this PR to `equals` and `compareTo` can be sufficiently offset by the improved `ArraysSupport.mismatch` mechanics. - PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1673056244
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Thu, 10 Aug 2023 11:28:39 GMT, Raffaello Giulietti wrote: >>> AFAIK, if you need reproducible randoms in tests, you should add the tags: >>> >>> ``` >>> * @key randomness >>> * @library /test/lib >>> ``` >>> >>> and initialize your random generator with >>> >>> ``` >>> import jdk.test.lib.RandomFactory; >>> ... >>> Random rnd = RandomFactory.getRandom(); >>> ``` >>> >>> This prints the seed to STDOUT. >> >> It'd be applicable for tests, but not for benchmarks. Also, the point that >> @cl4es seems to make is that randomness is captured and set up to reduce >> noise, not to be able to reproduce "benchmark failures". > > My bad. Forget my note > Some have a preference for providing a seed for `Random` instances in micros. > Either hard-coded or through a `@Param` (I find this a bit excessive). Doing > so might reduce run-to-run noise. I hear you, but unless your opinion is strong, I'll leave it as is. - PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289994437
Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v6]
On Thu, 10 Aug 2023 11:40:52 GMT, Pavel Rappo wrote: >> My bad. Forget my note > >> Some have a preference for providing a seed for `Random` instances in >> micros. Either hard-coded or through a `@Param` (I find this a bit >> excessive). Doing so might reduce run-to-run noise. > > I hear you, but unless your opinion is strong, I'll leave it as is. Hard-coding a seed would remove the run-to-run randomness, too, so would remove the need the `randomness` tag if this utility were to be used from a functional test. But yes, the reason to not do true randomness when setting up data for micros is to ensure we don't get multimodal results from arbitrary differences in the data setup. There are other ways around that, e.g. randomize data continually between iterations, run more forks to get more samples about flicker etc. A lot of work with an end result which is unlikely to add little more quality than a "random" set of data that we keep static from run-to-run. - PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289995785
Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
On Fri, 28 Jul 2023 08:40:30 GMT, Aleksey Shipilev wrote: >> Cristian Vat has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reduce allocations also for Matcher.usePattern > > Shouldn't the similar change be in `CIBackRef.match` too? The fact current > tests do not catch it makes me uneasy: the test coverage seems to be rather > low there. > > We need a regex expert to look at it. @rgiulietti @igraves might help us out > here? @shipilev anything I should do to continue here? - PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1673076902
Re: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
On Fri, 28 Jul 2023 08:40:30 GMT, Aleksey Shipilev wrote: >> Cristian Vat has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reduce allocations also for Matcher.usePattern > > Shouldn't the similar change be in `CIBackRef.match` too? The fact current > tests do not catch it makes me uneasy: the test coverage seems to be rather > low there. > > We need a regex expert to look at it. @rgiulietti @igraves might help us out > here? > @shipilev anything I should do to continue here? Not really, we need more reviewers. - PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1673080377
Re: RFR: 8313899: JVMCI exception Translation can fail in TranslatedException.
On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon wrote: > In a test that stresses metaspace (such as > `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also > uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in > `TranslatedException.` due to exhausted metaspace: > > java.lang.OutOfMemoryError: Metaspace > at > jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176) > at > jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61) > at > jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171) > > This PR pushes a fix such that this exception is properly handled in the VM > (i.e. causing a compilation bailout) instead of leading to a VM crash. > > The PR includes 2 bits of debug code guarded by system properties that enable > the handling to be tested in libgraal. The test itself is not included as > libgraal is not part of OpenJDK. Looks good to me too. - Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571741510
Re: RFR: 8313899: JVMCI exception Translation can fail in TranslatedException.
On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon wrote:
> In a test that stresses metaspace (such as
> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also
> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in
> `TranslatedException.` due to exhausted metaspace:
>
> java.lang.OutOfMemoryError: Metaspace
> at
> jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176)
> at
> jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61)
> at
> jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171)
>
> This PR pushes a fix such that this exception is properly handled in the VM
> (i.e. causing a compilation bailout) instead of leading to a VM crash.
>
> The PR includes 2 bits of debug code guarded by system properties that enable
> the handling to be tested in libgraal. The test itself is not included as
> libgraal is not part of OpenJDK.
src/hotspot/share/jvmci/jvmciEnv.cpp line 472:
> 470: vmSymbols::encodeThrowable_name(),
> 471: vmSymbols::encodeThrowable_signature(),
> &jargs, THREAD);
> 472: if (handle_pending_exception(THREAD, buffer, buffer_size)) {
This is the actual bug fix: handle any exception occurring in the Java upcall.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15198#discussion_r1290014253
Re: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from problem list
On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein wrote: > Please review this change to remove Unit-based tests in `java/lang/invoke` > from `jdk`'s problem list. The underlying race condition in jtreg was fixed > in release 7.3; which is now the default version used in JDK mainline > development. The bug management is a bit awkward here. I would suggest closing [JDK-8312482](https://bugs.openjdk.org/browse/JDK-8312482) as a dup of the codetools issue if allowed, else close it as "external" and link to the codetools issue. Thanks - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15206#pullrequestreview-1571839507
Re: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from problem list
On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein wrote: > Please review this change to remove Unit-based tests in `java/lang/invoke` > from `jdk`'s problem list. The underlying race condition in jtreg was fixed > in release 7.3; which is now the default version used in JDK mainline > development. Marked as reviewed by jpai (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/15206#pullrequestreview-1571889773
Re: RFR: 8313899: JVMCI exception Translation can fail in TranslatedException. [v2]
On Thu, 10 Aug 2023 13:41:05 GMT, Doug Simon wrote: >> In a test that stresses metaspace (such as >> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also >> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in >> `TranslatedException.` due to exhausted metaspace: >> >> java.lang.OutOfMemoryError: Metaspace >> at >> jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176) >> at >> jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61) >> at >> jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171) >> >> This PR pushes a fix such that this exception is properly handled in the VM >> (i.e. causing a compilation bailout) instead of leading to a VM crash. >> >> The PR includes 2 bits of debug code guarded by system properties that >> enable the handling to be tested in libgraal. The test itself is not >> included as libgraal is not part of OpenJDK. > > Doug Simon has updated the pull request incrementally with two additional > commits since the last revision: > > - guard test-only code with ASSERT instead of !PRODUCT > - omit test-only code in product build Still looks good to me. - Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571929038
Re: RFR: 8313899: JVMCI exception Translation can fail in TranslatedException. [v2]
> In a test that stresses metaspace (such as > `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also > uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in > `TranslatedException.` due to exhausted metaspace: > > java.lang.OutOfMemoryError: Metaspace > at > jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176) > at > jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61) > at > jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171) > > This PR pushes a fix such that this exception is properly handled in the VM > (i.e. causing a compilation bailout) instead of leading to a VM crash. > > The PR includes 2 bits of debug code guarded by system properties that enable > the handling to be tested in libgraal. The test itself is not included as > libgraal is not part of OpenJDK. Doug Simon has updated the pull request incrementally with two additional commits since the last revision: - guard test-only code with ASSERT instead of !PRODUCT - omit test-only code in product build - Changes: - all: https://git.openjdk.org/jdk/pull/15198/files - new: https://git.openjdk.org/jdk/pull/15198/files/529258a8..f160cb80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15198&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15198&range=00-01 Stats: 17 lines in 4 files changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15198/head:pull/15198 PR: https://git.openjdk.org/jdk/pull/15198
Re: RFR: 8312522: Implementation of Foreign Function & Memory API
On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous > iterations supported converting Java strings to and from native strings in > the UTF-8 encoding, we've extended the supported encoding to all the > encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the > `MemoryLayout::sequenceLayout` factory method which inferred the size of the > sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A > client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: > `Linker::canonicalLayouts`, which exposes a map containing the > platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access > varhandles, as well as byte offset and slice handles derived from memory > layouts, now feature an additional 'base offset' coordinate that is added to > the offset computed by the handle. This allows composing these handles with > other offset computation strategies that may not be based on the same memory > layout. This addresses use-cases where clients are working with 'dynamic' > layouts, whose size might not be known statically, such as variable length > arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now > redundant API. Clients can simply use the difference between the base address > of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of > `SegmentAllocator::allocateArray`, by renaming methods that both allocate + > initialize memory segments to `allocateFrom`. (see the original PR for the > problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the > documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to > make sure the `jdk_foreign` tests can pass on 32-bit machines, taking > linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API > required. The `Linker::nativeLinker` method is not longer allowed to throw an > `UnsupportedOperationException` on ... Thanks for the reviews so far. That also reminds me to mention: while there are a lot of files touched, most of the updates a simple 1 line changes to test files removing the `@enablePreview` tag from the jtreg test information. So, probably most of this is easy to review. - PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673384016
Re: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll() [v10]
On Sun, 6 Aug 2023 12:23:54 GMT, Wouter Born wrote: >> Doug Lea has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains 13 additional commits >> since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8301341 >> - Address more review comments >> - Address review comments >> - nitpicks >> - Merge branch 'openjdk:master' into JDK-8301341 >> - Accommodate white-box tests; use consistent constructions; minor >> improvements >> - Merge branch 'openjdk:master' into JDK-8301341 >> - Simplify contention handling; fix test >> - Fix inverted test assert; improve internal documentation; simplify code >> - Merge branch 'openjdk:master' into JDK-8301341 >> - ... and 3 more: https://git.openjdk.org/jdk/compare/c067d356...f53cee67 > > Thanks for making the fixes Doug! > Would it also be possible to backport these fixes to Java 17? > > It seems to be a very common issue for openHAB users now that they upgrade to > openHAB 4 which requires Java 17. > > See: > > * > https://community.openhab.org/t/consistent-100-cpu-use-of-safecall-queue-thread/143792 > * https://community.openhab.org/t/high-cpu-usage-after-migration-to-oh4/148200 @wborn I think 17 should also be OK modulo deleting 2 lines for pre-21 mentioned above. I only checked with 19 though.. - PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-1673399971
RFR: 8314085: Fixing scope from benchmark to thread for JMH tests having shared state
In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems. org/openjdk/bench/java/io/DataInputStreamTest.java org/openjdk/bench/java/lang/ArrayClone.java org/openjdk/bench/java/lang/StringCompareToDifferentLength.java org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java org/openjdk/bench/java/lang/StringComparisons.java org/openjdk/bench/java/lang/StringEquals.java org/openjdk/bench/java/lang/StringFormat.java org/openjdk/bench/java/lang/StringReplace.java org/openjdk/bench/java/lang/StringSubstring.java org/openjdk/bench/java/lang/StringTemplateFMT.java org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java org/openjdk/bench/java/security/CipherSuiteBench.java org/openjdk/bench/java/time/GetYearBench.java org/openjdk/bench/java/time/InstantBench.java org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java org/openjdk/bench/java/util/ListArgs.java org/openjdk/bench/java/util/LocaleDefaults.java org/openjdk/bench/java/util/TestAdler32.java org/openjdk/bench/java/util/TestCRC32.java org/openjdk/bench/java/util/TestCRC32C.java org/openjdk/bench/java/util/regex/Exponential.java org/openjdk/bench/java/util/regex/Primality.java org/openjdk/bench/java/util/regex/Trim.java org/openjdk/bench/javax/crypto/AESReinit.java org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java org/openjdk/bench/vm/compiler/Rotation.java org/openjdk/bench/vm/compiler/x86/ConvertF2I.java org/openjdk/bench/vm/compiler/x86/BasicRules.java Please review and provide your feedback. Thanks, Swati - Commit messages: - 8314085: Fixing scope from benchmark to thread for JMH tests having shared state Changes: https://git.openjdk.org/jdk/pull/15230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314085 Stats: 46 lines in 38 files changed: 0 ins; 0 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/15230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15230/head:pull/15230 PR: https://git.openjdk.org/jdk/pull/15230
RFR: 8314120: Add tests for FileDescriptor.sync
When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for FileDescriptor.sync that can be used to qualify the changes in that area. Additionally, we use FD.sync for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. It will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. BenchmarkMode CntScore Error Units # Before JDK-8312127 FileDescriptorSync.sync avgt 15 351,688 ? 2,477 ns/op # After JDK-8312127 FileDescriptorSync.sync avgt 15 353,331 ? 2,116 ns/op The new regression test completes in <0.5s on my Mac. - Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/15231/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15231&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314120 Stats: 155 lines in 2 files changed: 155 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15231.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15231/head:pull/15231 PR: https://git.openjdk.org/jdk/pull/15231
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v3]
> Please review this patch which adds a "jmodless" jlink mode to the JDK. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jmods`). This is > particularly useful to further reduce the size of a jlinked runtime. After > the removal of the concept of a JRE, a common distribution mechanism is still > the full JDK with all modules and packaged modules. However, packaged modules > can incur an additional size tax. For example in a container scenario it > could be useful to have a base JDK container including all modules, but > without also delivering the packaged modules. This comes at a size advantage > of `~25%`. Such a base JDK container could then be used to `jlink` > application specific runtimes, further reducing the size of the application > runtime image (App + JDK runtime; as a single image *or* separate bundles, > depending on the app being modularized). > > The basic design of this approach is to add a jlink plugin for tracking > non-class and non-resource files of a JDK install. I.e. files which aren't > present in the jimage (`lib/modules`). This enables producing a > `JmodLessArchive` class which has all the info of what constitutes the final > jlinked runtime. > > Basic usage example: > > $ diff -u <(./bin/java --list-modules --limit-modules java.se) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules java.se) > $ diff -u <(./bin/java --list-modules --limit-modules java.se) > <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules > --limit-modules jdk.jlink) > $ ls ../linux-x86_64-server-release/images/jdk/jmods > java.base.jmodjava.net.http.jmod java.sql.rowset.jmod > jdk.crypto.ec.jmod jdk.internal.opt.jmod > jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod > java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod > jdk.dynalink.jmod jdk.internal.vm.ci.jmod > jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod > java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod > jdk.editpad.jmod jdk.internal.vm.compiler.jmod > jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod > java.desktop.jmod java.scripting.jmod java.xml.jmod > jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod > jdk.jlink.jmod jdk.naming.dns.jmodjdk.unsupported... Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: - Implementation for run-image link and single-hop This uses a stamp file in 'lib/modules' jimage in order to recognize multi-hop links. However, this has the caveat of no longer producing reproducible builds as compared to a packaged module-based link. Add an option to allow for multi-hop, which disables the stamp file addition and makes it reproducible again. - Exit the jlink on modified files by default This is configurable so add tests for both scenarios. - Changes: - all: https://git.openjdk.org/jdk/pull/14787/files - new: https://git.openjdk.org/jdk/pull/14787/files/baeaaf5d..738b8a31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=01-02 Stats: 529 lines in 15 files changed: 450 ins; 45 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/14787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787 PR: https://git.openjdk.org/jdk/pull/14787
[jdk21] RFR: 8298095: Refine implSpec for SegmentAllocator
8298095: Refine implSpec for SegmentAllocator - Commit messages: - Backport 35b60f925a4e7e2e3f1ec7c5c1eee60206e7508a Changes: https://git.openjdk.org/jdk21/pull/172/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=172&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298095 Stats: 249 lines in 1 file changed: 147 ins; 21 del; 81 mod Patch: https://git.openjdk.org/jdk21/pull/172.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/172/head:pull/172 PR: https://git.openjdk.org/jdk21/pull/172
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v2]
On Tue, 8 Aug 2023 16:34:09 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a "jmodless" jlink mode to the JDK. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is particularly useful to further reduce the size of a jlinked runtime. >> After the removal of the concept of a JRE, a common distribution mechanism >> is still the full JDK with all modules and packaged modules. However, >> packaged modules can incur an additional size tax. For example in a >> container scenario it could be useful to have a base JDK container including >> all modules, but without also delivering the packaged modules. This comes at >> a size advantage of `~25%`. Such a base JDK container could then be used to >> `jlink` application specific runtimes, further reducing the size of the >> application runtime image (App + JDK runtime; as a single image *or* >> separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking >> non-class and non-resource files of a JDK install. I.e. files which aren't >> present in the jimage (`lib/modules`). This enables producing a >> `JmodLessArchive` class which has all the info of what constitutes the final >> jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmodjava.net.http.jmod java.sql.rowset.jmod >> jdk.crypto.ec.jmod jdk.internal.opt.jmod >> jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod >> jdk.dynalink.jmod jdk.internal.vm.ci.jmod >> jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod >> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod >> jdk.editpad.jmod jdk.internal.vm.compiler.jmod >> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod >> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod >> jdk.jlink.jmod jdk.naming.dns.j... > > Severin Gehwolf has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Use 'run-image' as the term shown with --verbose > - 8311302: Allow for jlinking a custom runtime without packaged modules > being present @AlanBateman Hi! Moving the [discusion](https://mail.openjdk.org/pipermail/leyden-dev/2023-July/000173.html) to this PR now. I've updated this patch to do single-hops only by default now. Looks like this: $ bin/jlink --add-modules java.base --output ../testme-java-base/ --verbose java.base jrt:/java.base (run-image) Providers: java.base provides java.nio.file.spi.FileSystemProvider used by java.base java.base provides java.util.random.RandomGenerator used by java.base Error: Run image links only allow single-hop. I'm not particularly fond of that, though, as there is a need to know what is single hop is and what not. My approach is adding a 0-sized stamp file to the `lib/modules` jimage, but that has the issue of now breaking comparison between a packaged module jlink vs. a runtime image using one. The same would be true for adding a file or appending the `jmod_resources` file with some info to know it's multi-hop. Some state needs to be there unless I'm missing something for this. For now an option suppresses creating that file so as to be able to keep asserting packaged vs run-image link and other properties in tests. I'd argue most of the time multi-hop would be OK, but default off and a switch to turn it on seems reasonable to me. Up for discussion... Also, if a file is modified the link fails unless it's turned off with an option. Looks like this: $ ./bin/jlink --add-modules java.base --output ../abort-on-mod --verbose java.base jrt:/java.base (run-image) Providers: java.base provides java.nio.file.spi.FileSystemProvider used by java.base java.base provides java.util.random.RandomGenerator used by java.base Error: java.lang.IllegalArgumentException: /disk/openjdk/upstream-sources/git/jdk-jdk/build/jmodless-copy-jmods-removed/conf/net.properties has been modified. Please double check! $ echo $? 1 Both things will have CLI options to a) make the exit on mod a warning only and b) allow multi-hop - some tests needed that. Hence, I've marked this
Re: RFR: 8041488: Locale-Dependent List Patterns [v7]
On Wed, 9 Aug 2023 23:39:24 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Small cleanup
>
> src/java.base/share/classes/java/text/ListFormat.java line 58:
>
>> 56: * .format(List.of("Foo", "Bar", "Baz"))
>> 57: * }
>> 58: * This will produce the concatenated list string, "Foo, Bar, and Baz"
>> as seen in
>
> With this sample code, if the Style is changed to SHORT, it would produce the
> same string. Would it be better to use the weekdays instead of Foo, Bar and
> Baz (as in the Unicode spec)? Esp. with the UNIT type, those examples
> explained it better, e.g. NARROW produces 3′ 7″.
>
> Also, if the instance is of STANDARD/SHORT, does it format List.of("January",
> "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches
> to 3 ft, 7 in? The format method states simply "Returns the string that
> consists of the input strings, concatenated with the patterns of this
> ListFormat." I wonder if it'd be helpful to explain a bit more or add one
> more sample.
In fact, the sample in LDML's page seems to be incorrect. `standard-short` in
English is defined as:
{0}, {1}
{0},
{1}
{0}, &
{1}
{0} &
{1}
in `en.xml` file. So `&` is expected rather than `and`.
> Also, if the instance is of STANDARD/SHORT, does it format List.of("January",
> "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches
> to 3 ft, 7 in?
No it does not. The `format()` method does not alter the passed input strings,
so it would not convert "January" to "Jan." even if `SHORT` Style is specified.
I have added some extra explanations, that those patterns vary depending on the
locale providers.
> src/java.base/share/classes/java/text/ListFormat.java line 71:
>
>> 69: * STANDARD
>> 70: * Foo, Bar, and Baz
>> 71: * Foo, Bar, & Baz
>
> Is "&" a typo? It's still "and" in the Unicode spec's "standard-short"
> format, e.g. "Jan., Feb., and Mar."
Again `ampersand` is the correct pattern for `SHORT` in English.
> src/java.base/share/classes/java/text/ListFormat.java line 408:
>
>> 406: var em = endPattern.matcher(source);
>> 407: Object parsed = null;
>> 408: if (sm.find(parsePos.index) && em.find(parsePos.index)) {
>
> Would it be better to call getIndex() instead? (same below)
Fixed.
> test/jdk/java/text/Format/ListFormat/TestListFormat.java line 157:
>
>> 155: "foo, bar, baz", true),
>> 156: arguments(Locale.US, ListFormat.Type.OR,
>> ListFormat.Style.NARROW,
>> 157: "foo, bar, or baz", true),
>
> Same as in the ListFormat class, the expected results are the same "foo, bar,
> or baz" when different Styles are specified.
Yes, those are exactly what are defined in CLDR. (They could have chosen `|`
for SHORT style, but that would be not so common in plain English I guess)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428317
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428359
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428267
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428459
Re: RFR: 8041488: Locale-Dependent List Patterns [v8]
> Introducing a new formatting class for locale-dependent list patterns. The > class is to provide the functionality from the Unicode Consortium's LDML > specification for [list > patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). > For example, given a list of String as "Monday", "Wednesday", "Friday", its > `format` method would produce "Monday, Wednesday, and Friday" in US English. > A CSR has also been drafted, and its draft javadoc can be viewed here: > https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments - Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/7760656a..5b536fab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=06-07 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130
Re: RFR: 8312522: Implementation of Foreign Function & Memory API [v2]
> This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous > iterations supported converting Java strings to and from native strings in > the UTF-8 encoding, we've extended the supported encoding to all the > encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the > `MemoryLayout::sequenceLayout` factory method which inferred the size of the > sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A > client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: > `Linker::canonicalLayouts`, which exposes a map containing the > platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access > varhandles, as well as byte offset and slice handles derived from memory > layouts, now feature an additional 'base offset' coordinate that is added to > the offset computed by the handle. This allows composing these handles with > other offset computation strategies that may not be based on the same memory > layout. This addresses use-cases where clients are working with 'dynamic' > layouts, whose size might not be known statically, such as variable length > arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now > redundant API. Clients can simply use the difference between the base address > of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of > `SegmentAllocator::allocateArray`, by renaming methods that both allocate + > initialize memory segments to `allocateFrom`. (see the original PR for the > problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the > documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to > make sure the `jdk_foreign` tests can pass on 32-bit machines, taking > linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API > required. The `Linker::nativeLinker` method is not longer allowed to throw an > `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - 8313894: Rename isTrivial linker option to critical Reviewed-by: pminborg, mcimadamore - 8313680: Disallow combining caputreCallState with isTrivial Reviewed-by: mcimadamore - Merge branch 'master' into JEP22 - use immutable map for fallback linker canonical layouts - 8313265: Move the FFM API out of preview Reviewed-by: mcimadamore - 8313005: Ensure native access check can fold away Reviewed-by: mcimadamore - 8312981: Make the linker API required Reviewed-by: mcimadamore - 8312615: Ensure jdk_foreign tests pass on linux-x86 Reviewed-by: mcimadamore - 8312186: TestStringEncodingFails for UTF-32 Reviewed-by: mcimadamore - 8312059: Clarify the documention for variadic functions 8310646: Javadoc around prototype-less functions might be incorrect Reviewed-by: mcimadamore - ... and 7 more: https://git.openjdk.org/jdk/compare/23fe2ece...74bbe721 - Changes: https://git.openjdk.org/jdk/pull/15103/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01 Stats: 2817 lines in 230 files changed: 1239 ins; 894 del; 684 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103
Re: RFR: 8312522: Implementation of Foreign Function & Memory API
On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous > iterations supported converting Java strings to and from native strings in > the UTF-8 encoding, we've extended the supported encoding to all the > encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the > `MemoryLayout::sequenceLayout` factory method which inferred the size of the > sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A > client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: > `Linker::canonicalLayouts`, which exposes a map containing the > platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access > varhandles, as well as byte offset and slice handles derived from memory > layouts, now feature an additional 'base offset' coordinate that is added to > the offset computed by the handle. This allows composing these handles with > other offset computation strategies that may not be based on the same memory > layout. This addresses use-cases where clients are working with 'dynamic' > layouts, whose size might not be known statically, such as variable length > arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now > redundant API. Clients can simply use the difference between the base address > of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of > `SegmentAllocator::allocateArray`, by renaming methods that both allocate + > initialize memory segments to `allocateFrom`. (see the original PR for the > problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the > documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to > make sure the `jdk_foreign` tests can pass on 32-bit machines, taking > linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API > required. The `Linker::nativeLinker` method is not longer allowed to throw an > `UnsupportedOperationException` on ... Addressing some offline review comments. Two more (small) changes have been added: - Disallow combining the `captureCallState` and `isTrivial` (see https://github.com/openjdk/panama-foreign/pull/856) - Rename `isTrivial` to `critical` (see https://github.com/openjdk/panama-foreign/pull/859) - PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673627002
[jdk21] Withdrawn: 8298095: Refine implSpec for SegmentAllocator
On Thu, 10 Aug 2023 16:54:35 GMT, Maurizio Cimadamore wrote: > 8298095: Refine implSpec for SegmentAllocator This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk21/pull/172
Integrated: 8313899: JVMCI exception Translation can fail in TranslatedException.
On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon wrote: > In a test that stresses metaspace (such as > `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also > uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in > `TranslatedException.` due to exhausted metaspace: > > java.lang.OutOfMemoryError: Metaspace > at > jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176) > at > jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61) > at > jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171) > > This PR pushes a fix such that this exception is properly handled in the VM > (i.e. causing a compilation bailout) instead of leading to a VM crash. > > The PR includes 2 bits of debug code guarded by system properties that enable > the handling to be tested in libgraal. The test itself is not included as > libgraal is not part of OpenJDK. This pull request has now been integrated. Changeset: 6f5c903d Author:Doug Simon URL: https://git.openjdk.org/jdk/commit/6f5c903d10aa5f7ff979a79f121609c167f88eff Stats: 60 lines in 6 files changed: 58 ins; 1 del; 1 mod 8313899: JVMCI exception Translation can fail in TranslatedException. Reviewed-by: never, thartmann - PR: https://git.openjdk.org/jdk/pull/15198
Re: RFR: 8313899: JVMCI exception Translation can fail in TranslatedException. [v2]
On Thu, 10 Aug 2023 13:56:37 GMT, Doug Simon wrote: >> In a test that stresses metaspace (such as >> `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also >> uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in >> `TranslatedException.` due to exhausted metaspace: >> >> java.lang.OutOfMemoryError: Metaspace >> at >> jdk.internal.vm.TranslatedException.encodeThrowable(java.base@21/TranslatedException.java:176) >> at >> jdk.internal.vm.TranslatedException.(java.base@21/TranslatedException.java:61) >> at >> jdk.internal.vm.VMSupport.encodeThrowable(java.base@21/VMSupport.java:171) >> >> This PR pushes a fix such that this exception is properly handled in the VM >> (i.e. causing a compilation bailout) instead of leading to a VM crash. >> >> The PR includes 2 bits of debug code guarded by system properties that >> enable the handling to be tested in libgraal. The test itself is not >> included as libgraal is not part of OpenJDK. > > Doug Simon has updated the pull request incrementally with two additional > commits since the last revision: > > - guard test-only code with ASSERT instead of !PRODUCT > - omit test-only code in product build Thanks for the reviews. - PR Comment: https://git.openjdk.org/jdk/pull/15198#issuecomment-1673739930
Re: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
> This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The main changes found in this patch come from the following PRs: > > 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous > iterations supported converting Java strings to and from native strings in > the UTF-8 encoding, we've extended the supported encoding to all the > encodings found in the `java.nio.charset.StandardCharsets` class. > 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the > `MemoryLayout::sequenceLayout` factory method which inferred the size of the > sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A > client is now required to explicitly specify the sequence size. > 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: > `Linker::canonicalLayouts`, which exposes a map containing the > platform-specific mappings of common C type names to memory layouts. > 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access > varhandles, as well as byte offset and slice handles derived from memory > layouts, now feature an additional 'base offset' coordinate that is added to > the offset computed by the handle. This allows composing these handles with > other offset computation strategies that may not be based on the same memory > layout. This addresses use-cases where clients are working with 'dynamic' > layouts, whose size might not be known statically, such as variable length > arrays, or variable size matrices. > 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now > redundant API. Clients can simply use the difference between the base address > of two memory segments. > 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of > `SegmentAllocator::allocateArray`, by renaming methods that both allocate + > initialize memory segments to `allocateFrom`. (see the original PR for the > problematic case) > 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the > documentation for variadic functions. > 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to > make sure the `jdk_foreign` tests can pass on 32-bit machines, taking > linux-x86 as a test bed. > 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API > required. The `Linker::nativeLinker` method is not longer allowed to throw an > `UnsupportedOperationException` on ... Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - enable fallback linker on linux x86 in GHA - make Arena::allocate abstract - Changes: - all: https://git.openjdk.org/jdk/pull/15103/files - new: https://git.openjdk.org/jdk/pull/15103/files/74bbe721..147e79d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01-02 Stats: 20 lines in 4 files changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15103.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103 PR: https://git.openjdk.org/jdk/pull/15103
RFR: 8314129: Make fields final in java.util.Scanner
Made a few fields `final` in java.util.Scanner. Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.` - Commit messages: - [PATHC] Make fields final in java.util.Scanner Changes: https://git.openjdk.org/jdk/pull/14863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314129 Stats: 34 lines in 1 file changed: 17 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14863/head:pull/14863 PR: https://git.openjdk.org/jdk/pull/14863
Re: RFR: 8314129: Make fields final in java.util.Scanner
On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov wrote: > Made a few fields `final` in java.util.Scanner. > Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.` Marked as reviewed by stsypanov (Author). - PR Review: https://git.openjdk.org/jdk/pull/14863#pullrequestreview-1528793589
Re: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API >> JEP for Java 22. The initial patch is composed of commits brought over >> directly from the [panama-foreign >> repo](https://github.com/openjdk/panama-foreign). The main changes found in >> this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous >> iterations supported converting Java strings to and from native strings in >> the UTF-8 encoding, we've extended the supported encoding to all the >> encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the >> `MemoryLayout::sequenceLayout` factory method which inferred the size of the >> sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A >> client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: >> `Linker::canonicalLayouts`, which exposes a map containing the >> platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access >> varhandles, as well as byte offset and slice handles derived from memory >> layouts, now feature an additional 'base offset' coordinate that is added to >> the offset computed by the handle. This allows composing these handles with >> other offset computation strategies that may not be based on the same memory >> layout. This addresses use-cases where clients are working with 'dynamic' >> layouts, whose size might not be known statically, such as variable length >> arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now >> redundant API. Clients can simply use the difference between the base >> address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of >> `SegmentAllocator::allocateArray`, by renaming methods that both allocate + >> initialize memory segments to `allocateFrom`. (see the original PR for the >> problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the >> documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to >> make sure the `jdk_foreign` tests can pass on 32-bit machines, taking >> linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API >> required. The `Linker::nativeLinker` method is not longer allowed to throw >> an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with two additional > commits since the last revision: > > - enable fallback linker on linux x86 in GHA > - make Arena::allocate abstract The few, simple NIO changes are fine. - PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673943826
RFR: 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
Add new test case with sample modules that contains some requires/exports/uses/provides. We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class. Follow up task from https://github.com/openjdk/jdk/pull/14408 - Commit messages: - cleanup - rename and cleanup - revert back to default size of 75 for module desriptors - add decompilation via javap - extract jimage - add some more opens and exports - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591 - Set module split size to 1 - fix test - test - ... and 2 more: https://git.openjdk.org/jdk/compare/509f80bb...9577e7e8 Changes: https://git.openjdk.org/jdk/pull/15234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311591 Stats: 240 lines in 10 files changed: 240 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234 PR: https://git.openjdk.org/jdk/pull/15234
Re: RFR: 8240567: MethodTooLargeException thrown while creating a jlink image [v19]
On Fri, 14 Jul 2023 16:08:12 GMT, Mandy Chung wrote: >>> It's looking pretty good. >> >> Thank you! >> >>> About the test, I don't see `ArrayList::add` in the generated bytecode of >>> `sub2-13`. The dedup string set is used for the targets of qualified >>> exports and opens and uses. The modifiers set of `requires` is deduplicated >>> but not the required module names. >> >> Thank you for the hint. >> >>> I assume you want this be backported. If so, we should give it some baked >>> time after it's integrated to the main line. >> >> Sounds great! >> >>> I'm okay if you want to extend the test in a follow up. >> >> That would be great. Will take time to craft a proper setting. > > @koppor do you have any update on a new test for > [JDK-8311591](https://bugs.openjdk.org/browse/JDK-8311591)? @mlchung Pardon for the delay, we now created a PR with a test case https://github.com/openjdk/jdk/pull/15234 - PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1673959119
Re: RFR: 8041488: Locale-Dependent List Patterns [v7]
On Thu, 10 Aug 2023 16:59:14 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/text/ListFormat.java line 58:
>>
>>> 56: * .format(List.of("Foo", "Bar", "Baz"))
>>> 57: * }
>>> 58: * This will produce the concatenated list string, "Foo, Bar, and Baz"
>>> as seen in
>>
>> With this sample code, if the Style is changed to SHORT, it would produce
>> the same string. Would it be better to use the weekdays instead of Foo, Bar
>> and Baz (as in the Unicode spec)? Esp. with the UNIT type, those examples
>> explained it better, e.g. NARROW produces 3′ 7″.
>>
>> Also, if the instance is of STANDARD/SHORT, does it format
>> List.of("January", "February", "March") and return "Jan., Feb., and Mar.",
>> or 3 feet, 7 inches to 3 ft, 7 in? The format method states simply "Returns
>> the string that consists of the input strings, concatenated with the
>> patterns of this ListFormat." I wonder if it'd be helpful to explain a bit
>> more or add one more sample.
>
> In fact, the sample in LDML's page seems to be incorrect. `standard-short` in
> English is defined as:
>
>
> {0}, {1}
> {0},
> {1}
> {0}, &
> {1}
> {0} &
> {1}
>
>
> in `en.xml` file. So `&` is expected rather than `and`.
>
>> Also, if the instance is of STANDARD/SHORT, does it format
>> List.of("January", "February", "March") and return "Jan., Feb., and Mar.",
>> or 3 feet, 7 inches to 3 ft, 7 in?
>
> No it does not. The `format()` method does not alter the passed input
> strings, so it would not convert "January" to "Jan." even if `SHORT` Style is
> specified. I have added some extra explanations, that those patterns vary
> depending on the locale providers.
Ah, I see. Those samples did give an impression that the format does more than
concatenation.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290711203
Re: RFR: 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder [v2]
> Add new test case with sample modules that contains some > requires/exports/uses/provides. > > We are just unsure if and how we should add some last step of verificaiton > with the extracted and decompiled class. > > Follow up task from https://github.com/openjdk/jdk/pull/14408 Christoph has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder Co-authored-by: Oliver Kopp - Changes: https://git.openjdk.org/jdk/pull/15234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=01 Stats: 239 lines in 9 files changed: 239 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234 PR: https://git.openjdk.org/jdk/pull/15234
Re: RFR: 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
On Thu, 10 Aug 2023 21:42:41 GMT, Christoph wrote: > Add new test case with sample modules that contains some > requires/exports/uses/provides. > > We are just unsure if and how we should add some last step of verificaiton > with the extracted and decompiled class. > > Follow up task from https://github.com/openjdk/jdk/pull/14408 We accidently pushed the full internal history - and "immediatly" squashed into one commit. From now on, we will update the branch "as usual" - PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1673981735
RFR: 8313904: [macos] All signing tests which verifies unsigned app images are failing
- This is regression from [JDK-8298488](https://bugs.openjdk.org/browse/JDK-8298488). - Since JDK-8298488 unsigned app bundles are ad-hoc signed and `codesign` will report that app bundle is signed and thus our tests failed. - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate. - Unsigned post process image will be ad-hoc re-sign when generating DMG or PKG, since we adding `.package` file which makes ad-hoc signature invalid. This is similar to [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462). - Commit messages: - 8313904: [macos] All signing tests which verifies unsigned app images are failing Changes: https://git.openjdk.org/jdk/pull/15235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313904 Stats: 94 lines in 8 files changed: 58 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/15235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15235/head:pull/15235 PR: https://git.openjdk.org/jdk/pull/15235
Re: RFR: 8313904: [macos] All signing tests which verifies unsigned app images are failing
> On Aug 10, 2023, at 6:21 PM, Alexander Matveev wrote: > > - Fixed tests by checking that all app bundles are signed and by checking how > they signed ad-hoc vs actual certificate. How is ad-hoc signing done?
Re: RFR: 8314129: Make fields final in java.util.Scanner
On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov wrote: > Made a few fields `final` in java.util.Scanner. > Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.` Marked as reviewed by liach (Author). - PR Review: https://git.openjdk.org/jdk/pull/14863#pullrequestreview-1572853738
Re: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee wrote: >> This patch contains the implementation of the foreign linker & memory API >> JEP for Java 22. The initial patch is composed of commits brought over >> directly from the [panama-foreign >> repo](https://github.com/openjdk/panama-foreign). The main changes found in >> this patch come from the following PRs: >> >> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous >> iterations supported converting Java strings to and from native strings in >> the UTF-8 encoding, we've extended the supported encoding to all the >> encodings found in the `java.nio.charset.StandardCharsets` class. >> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the >> `MemoryLayout::sequenceLayout` factory method which inferred the size of the >> sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A >> client is now required to explicitly specify the sequence size. >> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: >> `Linker::canonicalLayouts`, which exposes a map containing the >> platform-specific mappings of common C type names to memory layouts. >> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access >> varhandles, as well as byte offset and slice handles derived from memory >> layouts, now feature an additional 'base offset' coordinate that is added to >> the offset computed by the handle. This allows composing these handles with >> other offset computation strategies that may not be based on the same memory >> layout. This addresses use-cases where clients are working with 'dynamic' >> layouts, whose size might not be known statically, such as variable length >> arrays, or variable size matrices. >> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now >> redundant API. Clients can simply use the difference between the base >> address of two memory segments. >> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of >> `SegmentAllocator::allocateArray`, by renaming methods that both allocate + >> initialize memory segments to `allocateFrom`. (see the original PR for the >> problematic case) >> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the >> documentation for variadic functions. >> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to >> make sure the `jdk_foreign` tests can pass on 32-bit machines, taking >> linux-x86 as a test bed. >> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API >> required. The `Linker::nativeLinker` method is not longer allowed to throw >> an `UnsupportedO... > > Jorn Vernee has updated the pull request incrementally with two additional > commits since the last revision: > > - enable fallback linker on linux x86 in GHA > - make Arena::allocate abstract Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview? - PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1674051619
Re: RFR: 8313904: [macos] All signing tests which verifies unsigned app images are failing
> On Aug 10, 2023, at 6:35 PM, Michael Hall wrote: > > > >> On Aug 10, 2023, at 6:21 PM, Alexander Matveev wrote: >> >> - Fixed tests by checking that all app bundles are signed and by checking >> how they signed ad-hoc vs actual certificate. > > How is ad-hoc signing done? > > If it’s this, I guess I got it https://developer.apple.com/documentation/security/seccodesignatureflags/1397793-adhoc I assume done with jpackage by indicating something like —mac-sign only? If wrong feel free to correct.
Re: RFR: 8313904: [macos] All signing tests which verifies unsigned app images are failing
Hi Michael, On Aug 10, 2023, at 6:11 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Aug 10, 2023, at 6:35 PM, Michael Hall mailto:mik3h...@gmail.com>> wrote: On Aug 10, 2023, at 6:21 PM, Alexander Matveev mailto:almat...@openjdk.org>> wrote: - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate. How is ad-hoc signing done? If it’s this, I guess I got it https://developer.apple.com/documentation/security/seccodesignatureflags/1397793-adhoc Yes, this is how it is done. I assume done with jpackage by indicating something like —mac-sign only? If wrong feel free to correct. No, it is always done if —mac-sign is NOT specified and we doing ad-hoc signing on app bundle only. PKG will not be ad-hoc signed. If —mac-sign is provided we will use certificate provided with —mac-sign to sign app image and PKG as before. Thanks, Alexander
Withdrawn: JDK-8077371: Binary files in JAXP test should be removed
On Wed, 19 Apr 2023 15:51:01 GMT, Mahendra Chhipa wrote: > Test is updated to create the binary files during test execution. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/13537
Re: RFR: 8313904: [macos] All signing tests which verifies unsigned app images are failing
>> >> I assume done with jpackage by indicating something like —mac-sign only? If >> wrong feel free to correct. > > No, it is always done if —mac-sign is NOT specified and we doing ad-hoc > signing on app bundle only. PKG will not be ad-hoc signed. > If —mac-sign is provided we will use certificate provided with —mac-sign to > sign app image and PKG as before. > > Thanks, > Alexander I always do dmg or app-image for quick testing. I haven’t done any pkg yet. So if I understand correctly now for app bundle types - dmg or app-image, some signing is always done. Certificate if signing is indicated and it is provided or adhoc if it isn’t indicated as a default. I didn’t know this. Thanks Mike
