From alanb at openjdk.org  Fri Sep  1 06:00:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Sep 2023 06:00:52 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <4cXPxtuv8uwl_wDxn3OiRvNqJcMj-OCEEx0o3RPyJ1E=.2c57d621-4d5e-49ac-acc4-3c35208f6f04@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <7MFImR__mtWC0mLIGyTuuvFdgUQ6OA5le3ITO12R6go=.45d4cae2-60b2-4e10-8178-1f41b8c27b0e@github.com>
 <4cXPxtuv8uwl_wDxn3OiRvNqJcMj-OCEEx0o3RPyJ1E=.2c57d621-4d5e-49ac-acc4-3c35208f6f04@github.com>
Message-ID: <O6oFJCv29J2cjRwhRTYdi7pWgHuM4tATsPbhJsYlSD4=.97471e4a-8a7e-404d-babb-35b312c4b3af@github.com>

On Thu, 31 Aug 2023 21:09:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 919:
>> 
>>> 917:             } else if (!sourceAttrs.isSymbolicLink() || flags.followLinks) {
>>> 918:                 // Ensure source can be read
>>> 919:                 provider.checkAccess(source, AccessMode.READ);
>> 
>> I don't think this will work with a SM set as that will trigger a check that the SM will allow read before it checks if there is read access at the file system level (move is specified to check the SM for write access to both source and target).
>
> I modified it in f09b468031ad542ba11e491a8091ea96a12d311d only to verify that the source has write access at the file system level.
> 
> I think that checkRead(), however, should be called if the move is effected as a copy + delete instead of as a rename. In this case,  move() calls copyFile() which does not check with the SM that there is permission to read the source. In copy(), checkRead() is called before copyFile() is invoked.

The spec for Files.move is that the SM is called to checkWrite on both source and target. I would need to dig into ancient history to page in the reasons why it's not checkDelete on the source and checkWrite on the target.  In any case, for the change here, it can't introduce a checkRead without doing a spec change. So checking it to use provider.checkAccess is right as that will just check file access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1312603803

From jvernee at openjdk.org  Mon Sep  4 08:16:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 08:16:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v6]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <xGH-7rk8B9PVRTVwaNbwN5mEVjPlBOjq0slCXueo_r4=.0583dae6-bc4c-461c-8657-f23f5c685d84@github.com>

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

 - Merge branch 'master' into JEP22
 - Merge branch 'master' into JEP22
 - remove spurious imports
 - enable fallback linker on linux x86 in GHA
 - make Arena::allocate abstract
 - 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
 - ... and 12 more: https://git.openjdk.org/jdk/compare/adfc1d6c...fd0512f8

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=05
  Stats: 2839 lines in 233 files changed: 1257 ins; 894 del; 688 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

From jvernee at openjdk.org  Mon Sep  4 08:25:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 08:25:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v7]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <-iK5sthUj7XUrkiRP38qwQ3mknsNaR70ipgnvOhdykY=.0093ab55-a85a-492f-95c7-2fab747eb551@github.com>

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

  add test for unmodifiable canonical layouts map

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/fd0512f8..efc5ef4a

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

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 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

From jvernee at openjdk.org  Mon Sep  4 10:56:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 10:56:09 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v8]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <FbEJKd-vkBUsk7iQcQ6Nby0m46b8JNBVH81OxYwgeVg=.dc5e32f8-9df1-4e04-9b2a-8467382764eb@github.com>

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

  fix TestIllegalLink on x86

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/efc5ef4a..470fcb9d

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

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 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

From lkorinth at openjdk.org  Mon Sep  4 11:04:44 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 4 Sep 2023 11:04:44 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.

What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1705068700

From jvernee at openjdk.org  Mon Sep  4 11:33:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 11:33:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v9]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <gyFxuZAluFFUxkZ8bJhqT2_kdiGQ3VGfCGHatsRKU4U=.104b80d4-1fc3-45bb-a2c0-db7adb726176@github.com>

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

  remove unsupported linker test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/470fcb9d..ea3daaed

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

  Stats: 40 lines in 1 file changed: 0 ins; 40 del; 0 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

From duke at openjdk.org  Mon Sep  4 15:53:45 2023
From: duke at openjdk.org (Thomas Obermeier)
Date: Mon, 4 Sep 2023 15:53:45 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <mHvibPipb0IQ8OZCWl38xw1d6VenJNwccDN4-Oh0HkA=.7d521288-a0b0-49aa-87dc-9bd2464d1343@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <Bbmrnkn3boAVs4Y3flqeHVOavktxAX2hIoU_eAX6z68=.1394bff7-52c7-4b4d-94a5-3e58e58e0bd2@github.com>
 <Gozvi5lCWDMWxzAxed79Qz0EMclbyPDYjccyzarCNhk=.eae248e4-d990-45d9-aa71-0f5da7253a5f@github.com>
 <G8JGBTQkuDyYM6O0WHmBQXL4KpHWb44BueqENfR9q9g=.d9639991-9b30-44d2-872c-4392fa8c8671@github.com>
 <5ai8MHV2EQmFEcuMNWYM7Rz88cUl9dVnXNQolLQ3Jp8=.af5976df-6b30-4842-9b5a-7550e2fcdd0a@github.com>
 <mRk_D4IlAIBINmnOJwXjWPMJsDFRbTgKMFeNvp2Ujw0=.a4dda300-06db-4904-b307-3d5e6d886731@github.com>
 <-6rjVxKJKaCis7qu8jwSTxqsqXtGtrvpd4hY-JA3TZ0=.2a9ba8ab-8c14-48eb-a35d-3b3c150740f9@github.com>
 <nrfXk_fFhl-fb6q9mKmS6RyoSPgjFfe3Qm_5Da1v0ME=.0f867df2-2cef-4db2-a6ed-59c46e6b2312@github.com>
 <mHvibPipb0IQ8OZCWl38xw1d6VenJNwccDN4-Oh0HkA=.7d521288-a0b0-49aa-87dc-9bd2464d1343@github.com>
Message-ID: <9Ar-hGw0vyn5twftkg57147cxlRDaTnjtmibKOfkAlA=.fc85312d-e5d8-488a-a7a5-46a6f6006049@github.com>

On Thu, 3 Aug 2023 12:06:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi @AlanBateman , 
>> 
>>  I ran the Jtreg tests on **jdk17** and observed  the following tests passed unexpectedly when I set the **VM_OPTIONS to `-Djdk.net.usePlainDatagramSocketImpl=true`**
>> 
>> 1. java/net/MulticastSocket/B6427403.java
>> 2. java/net/MulticastSocket/NoLoopbackPackets.java
>> 3. java/net/MulticastSocket/SetLoopbackMode.java
>> 4. java/net/MulticastSocket/Test.java
>> 
>> I am curious about how setting the `jdk.net.usePlainDatagramSocketImpl` property impacts their behavior. I would like to understand why they pass with this configuration and whether it has any implications.
>> 
>> Could you please share your insights on this matter? I appreciate your assistance in understanding this behavior and ensuring the correctness of the tests.
>> 
>> Thank you.
>
>> I am curious about how setting the `jdk.net.usePlainDatagramSocketImpl` property impacts their behavior. I would like to understand why they pass with this configuration and whether it has any implications.
>> 
>> Could you please share your insights on this matter? I appreciate your assistance in understanding this behavior and ensuring the correctness of the tests.
> 
> I think this issue needs an authoritative summary on what AIX supports and doesn't support. The observations reported conflict with some of the comments so I don't think I can say definitely if there are code or test changes required. 
> 
> For a long time, Net.canJoin6WithIPv4Group() has returned "false" on AIX so there is no attempt to join IPv4 multicast groups with a dual IPv4/IPv6 socket. DatagramChannel has supported multicasting since JDK 7 (2011) so if there were issues or test failures on AIX then surely they would have been noticed before now, or maybe all the test were excluded, or maybe the testing was done with IPv6 disabled.
> 
> The old DatagramSocketImpl implementation didn't have a setting/configuration to say if a dual IPv4/IPv6 socket could join an IPv4 multicast group, it just attempted it. Your results suggests that it works, which is surprising. Does AIX have the equivalent of strace to trace system calls? It might be useful to confirm that the socket is actually IPv6 and that it joining IPv4 multicast groups.

> > @AlanBateman , is it possible if there is a central place where the change could me made for fixing all of the multicast test cases?
...
> For the networking and NIO tests then you probably should look at jdk.test.lib.NetworkConfiguration. That has a number of AIX specific comments that may be out of date. ...

Created https://bugs.openjdk.org/browse/JDK-8315651 to address jdk.test.lib.NetworkConfiguration.

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

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1705474529

From jvernee at openjdk.org  Mon Sep  4 15:54:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 15:54:41 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>

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

 - 8315096: Allowed access modes in memory segment should depend on layout alignment
   
   Reviewed-by: psandoz
 - Add missing @implSpec to AddressLayout
   
   Reviewed-by: pminborg
 - Fix misc typos in FFM API javadoc
   
   Reviewed-by: jvernee
 - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two)
   
   Reviewed-by: pminborg
 - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle
   
   Reviewed-by: jvernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/ea3daaed..de3e7479

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

  Stats: 306 lines in 6 files changed: 218 ins; 12 del; 76 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

From jvernee at openjdk.org  Mon Sep  4 15:55:02 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Sep 2023 15:55:02 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v9]
In-Reply-To: <gyFxuZAluFFUxkZ8bJhqT2_kdiGQ3VGfCGHatsRKU4U=.104b80d4-1fc3-45bb-a2c0-db7adb726176@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <gyFxuZAluFFUxkZ8bJhqT2_kdiGQ3VGfCGHatsRKU4U=.104b80d4-1fc3-45bb-a2c0-db7adb726176@github.com>
Message-ID: <k2eHr5rwQCEXzupBhVDuk1wLTAAI7XBNZpoLeXTByGA=.c0b87fb2-fed7-4e7a-8163-990b32b27cef@github.com>

On Mon, 4 Sep 2023 11:33:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   remove unsupported linker test

Adding a few more minor fixes:
- Clarifying javadoc comments wrt which exceptions are thrown by handles derived from layouts: https://github.com/openjdk/panama-foreign/pull/869 & https://github.com/openjdk/panama-foreign/pull/872
- Fixing typos: https://github.com/openjdk/panama-foreign/pull/873
- Missing `@implspec` in AddressLayout: https://github.com/openjdk/panama-foreign/pull/877
- Correct the exception that is thrown for an unsupported access using a var handle: https://github.com/openjdk/panama-foreign/pull/876

Only the latter change is really significant (see the original PR)

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1705475550

From alanb at openjdk.org  Tue Sep  5 06:56:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Sep 2023 06:56:39 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <cWAnz6vTw8feTQwJ1WF4tprowvnIDZFMI9Cbjgs_ebU=.1621df98-6a7f-4966-a45f-35f04a1636a9@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <cWAnz6vTw8feTQwJ1WF4tprowvnIDZFMI9Cbjgs_ebU=.1621df98-6a7f-4966-a45f-35f04a1636a9@github.com>
Message-ID: <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>

On Thu, 31 Aug 2023 21:09:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Check file system access only for move; add move sub-test

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 136:

> 134:             // First ensure source can be read
> 135:             source.getFileSystem().provider().checkAccess(source,
> 136:                                                           AccessMode.READ);

This looks right for the cross-provider case. Minor nit is that you don't ned the line break here. Also the existing comments started in lower case.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:

> 918:                 // Ensure source can be moved
> 919:                 try {
> 920:                     access(source, W_OK);

Are you sure W_OK is correct and not R_OK or R_OK|W_OK ?

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1050:

> 1048:             else if (!sourceAttrs.isSymbolicLink() || flags.followLinks)
> 1049:                 // Ensure source can be read
> 1050:                 provider.checkAccess(source, AccessMode.READ);

I think access(source, R_OK) would be better here, otherwise the additional SM check is observable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1315444819
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1315448193
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1315448697

From duke at openjdk.org  Tue Sep  5 08:09:41 2023
From: duke at openjdk.org (Deepa Kumari)
Date: Tue, 5 Sep 2023 08:09:41 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <59ZEL6zQy8mj2QsiilDF-jkZnQbSTwcZsU6n1DgCMIk=.31c2ea26-3650-4199-8d21-3739e25f13f9@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <59ZEL6zQy8mj2QsiilDF-jkZnQbSTwcZsU6n1DgCMIk=.31c2ea26-3650-4199-8d21-3739e25f13f9@github.com>
Message-ID: <u7iWUr64EB3fp2PFkFjZzeAnHSb2wqkAl-mO1CXc2u0=.aee45cc5-92cb-4537-a8bc-ed270555d47f@github.com>

On Sun, 6 Aug 2023 13:47:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
>> 
>> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
>> 
>> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
>> 
>> 
>> 
>> 
>> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)
>
> src/java.base/share/classes/sun/nio/ch/SelectorProviderImpl.java line 58:
> 
>> 56: 
>> 57:     public DatagramChannel openUninterruptibleDatagramChannel(ProtocolFamily family) throws IOException {
>> 58:     if(family == null)
> 
> Suggestion:
> 
>     if (family == null)

Thank you @turbanoff for highlighting this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14142#discussion_r1315532078

From bpb at openjdk.org  Tue Sep  5 16:54:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 16:54:38 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <O6oFJCv29J2cjRwhRTYdi7pWgHuM4tATsPbhJsYlSD4=.97471e4a-8a7e-404d-babb-35b312c4b3af@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <7MFImR__mtWC0mLIGyTuuvFdgUQ6OA5le3ITO12R6go=.45d4cae2-60b2-4e10-8178-1f41b8c27b0e@github.com>
 <4cXPxtuv8uwl_wDxn3OiRvNqJcMj-OCEEx0o3RPyJ1E=.2c57d621-4d5e-49ac-acc4-3c35208f6f04@github.com>
 <O6oFJCv29J2cjRwhRTYdi7pWgHuM4tATsPbhJsYlSD4=.97471e4a-8a7e-404d-babb-35b312c4b3af@github.com>
Message-ID: <HSzV1HGWmTNilPnaxszlwE37T2mkIf-5n6KRW6JO_V0=.18c4f7f4-767c-4126-b141-7203d1460452@github.com>

On Fri, 1 Sep 2023 05:57:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So checking it to use provider.checkAccess is right as that will just check file access.

Here I think you must've intended `access()` and not `checkAccess()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316150645

From bpb at openjdk.org  Tue Sep  5 16:57:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 16:57:39 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <cWAnz6vTw8feTQwJ1WF4tprowvnIDZFMI9Cbjgs_ebU=.1621df98-6a7f-4966-a45f-35f04a1636a9@github.com>
 <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>
Message-ID: <meL5MVc6lyNK6zzr7Vh9SQRTwmdyta0pf_NADV6fsig=.cac35cf1-10a9-4d25-a9c8-a46695b4605f@github.com>

On Tue, 5 Sep 2023 06:53:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Check file system access only for move; add move sub-test
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:
> 
>> 918:                 // Ensure source can be moved
>> 919:                 try {
>> 920:                     access(source, W_OK);
> 
> Are you sure W_OK is correct and not R_OK or R_OK|W_OK ?

After all I think `R_OK|W_OK` would cover both the atomic and non-atomic (copy + delete) cases.

> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1050:
> 
>> 1048:             else if (!sourceAttrs.isSymbolicLink() || flags.followLinks)
>> 1049:                 // Ensure source can be read
>> 1050:                 provider.checkAccess(source, AccessMode.READ);
> 
> I think access(source, R_OK) would be better here, otherwise the additional SM check is observable.

An oversight; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316153651
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316154013

From bpb at openjdk.org  Tue Sep  5 17:05:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 17:05:33 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <cWAnz6vTw8feTQwJ1WF4tprowvnIDZFMI9Cbjgs_ebU=.1621df98-6a7f-4966-a45f-35f04a1636a9@github.com>
 <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>
Message-ID: <36blem7FWQy8aCDFgoQEFfHMFa4OGxy6MnZeZ_zvy6s=.7b472aab-bc7f-48c0-b066-68eeb5e09b7d@github.com>

On Tue, 5 Sep 2023 06:49:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Check file system access only for move; add move sub-test
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 136:
> 
>> 134:             // First ensure source can be read
>> 135:             source.getFileSystem().provider().checkAccess(source,
>> 136:                                                           AccessMode.READ);
> 
> This looks right for the cross-provider case. Minor nit is that you don't ned the line break here. Also the existing comments started in lower case.

Fixed in e226096d15b47bee7cee20ec2994bca93a071433.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316158145

From bpb at openjdk.org  Tue Sep  5 17:05:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 17:05:29 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>

> Check that the source is readable before deleting the destination.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8073061: Address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15501/files
  - new: https://git.openjdk.org/jdk/pull/15501/files/f09b4680..e226096d

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

  Stats: 13 lines in 2 files changed: 5 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15501/head:pull/15501

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

From bpb at openjdk.org  Tue Sep  5 17:05:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 17:05:36 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v2]
In-Reply-To: <meL5MVc6lyNK6zzr7Vh9SQRTwmdyta0pf_NADV6fsig=.cac35cf1-10a9-4d25-a9c8-a46695b4605f@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <cWAnz6vTw8feTQwJ1WF4tprowvnIDZFMI9Cbjgs_ebU=.1621df98-6a7f-4966-a45f-35f04a1636a9@github.com>
 <8aZ21DTyxPkko6FbX9rMng6TYm8PGxmiysZK4c0bJ_U=.301f84a4-bb0d-429d-9449-141d7d1361f5@github.com>
 <meL5MVc6lyNK6zzr7Vh9SQRTwmdyta0pf_NADV6fsig=.cac35cf1-10a9-4d25-a9c8-a46695b4605f@github.com>
Message-ID: <z1relJ8BgSi7mMeFCY4bzca6ATUT_7L47gNQ4M7m5Sg=.54807432-c04c-4e57-9621-11a8d566b058@github.com>

On Tue, 5 Sep 2023 16:54:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:
>> 
>>> 918:                 // Ensure source can be moved
>>> 919:                 try {
>>> 920:                     access(source, W_OK);
>> 
>> Are you sure W_OK is correct and not R_OK or R_OK|W_OK ?
>
> After all I think `R_OK|W_OK` would cover both the atomic and non-atomic (copy + delete) cases.

So changed in e226096d15b47bee7cee20ec2994bca93a071433.

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1050:
>> 
>>> 1048:             else if (!sourceAttrs.isSymbolicLink() || flags.followLinks)
>>> 1049:                 // Ensure source can be read
>>> 1050:                 provider.checkAccess(source, AccessMode.READ);
>> 
>> I think access(source, R_OK) would be better here, otherwise the additional SM check is observable.
>
> An oversight; thanks.

Fixed in e226096d15b47bee7cee20ec2994bca93a071433.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316158992
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1316158385

From rriggs at openjdk.org  Tue Sep  5 18:08:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Sep 2023 18:08:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
Message-ID: <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>

On Mon, 4 Sep 2023 11:01:23 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca

The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.

There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
@AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
Every test writer should be aware that additional command line options may be mixed in.

There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.

As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707072375

From psandoz at openjdk.org  Tue Sep  5 22:03:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 5 Sep 2023 22:03:49 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
Message-ID: <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>

On Mon, 4 Sep 2023 15:54:41 GMT, Jorn Vernee <jvernee at openjdk.org> 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 five additional commits since the last revision:
> 
>  - 8315096: Allowed access modes in memory segment should depend on layout alignment
>    
>    Reviewed-by: psandoz
>  - Add missing @implSpec to AddressLayout
>    
>    Reviewed-by: pminborg
>  - Fix misc typos in FFM API javadoc
>    
>    Reviewed-by: jvernee
>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two)
>    
>    Reviewed-by: pminborg
>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle
>    
>    Reviewed-by: jvernee

Recommend you do a sweep through the code for unused imports and fields and any rogue `@since` in the internal classes.

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 53:

> 51:  *
> 52:  * @implSpec
> 53:  * This class is immutable, thread-safe and <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>.

Strictly speaking it's the implementations, as stated in the `Linker`:

* Implementations of this interface are immutable, thread-safe and <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>.

src/java.base/share/classes/java/lang/foreign/Linker.java line 152:

> 150:  * <p>
> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided
> 152:  * here will assume these platform-dependent mappings):

Up to you, but it might be useful to link to the ABI specifications if the links are considered stable.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 439:

> 437:      * </ul>
> 438:      * <p>
> 439:      * If the provided layout path {@code P} contains no dereference elements, then the offset of the access operation is

Suggestion:

     * If the provided layout path {@code P} contains no dereference elements, then the offset {@code O} of the access operation is

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 443:

> 441:      *
> 442:      * {@snippet lang = "java":
> 443:      * offset = this.offsetHandle(P).invokeExact(B, I1, I2, ... In);

Suggestion:

     * O = this.offsetHandle(P).invokeExact(B, I1, I2, ... In);

To align with the use of `O` later on.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 536:

> 534:      * </ul>
> 535:      * <p>
> 536:      * The offset of the returned segment is computed as if by a call to a

Suggestion:

     * The offset {@code O} of the returned segment is computed as if by a call to a

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 154:

> 152:  *     MemoryLayout.sequenceLayout(4, ValueLayout.JAVA_INT).withName("data") // array of 4 elements
> 153:  * );
> 154:  * VarHandle intHandle = segmentLayout.varHandle(MemoryLayout.PathElemenet.groupElement("data"),

Suggestion:

 * VarHandle intHandle = segmentLayout.varHandle(MemoryLayout.PathElement.groupElement("data"),

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8027:

> 8025:      * @since 19
> 8026:      */
> 8027:     @PreviewFeature(feature=PreviewFeature.Feature.FOREIGN)

Unused import to `PreviewFeature`, and possibly others too.

src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 45:

> 43:             case DOUBLE_BYTE -> readFast_short(segment, offset, charset);
> 44:             case QUAD_BYTE -> readFast_int(segment, offset, charset);
> 45:             default -> throw new UnsupportedOperationException("Unsupported charset: " + charset);

Is this necessary, since the switch expression should be exhaustive over all the enum values?

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

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1611924844
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316401360
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316402470
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316409959
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316410079
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316414805
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316437803
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316457079
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1316444767

From bpb at openjdk.org  Tue Sep  5 22:04:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Sep 2023 22:04:58 GMT
Subject: RFR: 8315485: (fs) Move java/nio/file/Path/Misc.java tests into
 java/nio/file/Path/PathOps.java
Message-ID: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>

In the `java/nio/file/Path` tests, add to `PathOps` tests equivalent to those in `Misc` and then remove the latter.

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

Commit messages:
 - 8315485: Remove Misc.java
 - 8315485: (fs) Move java/nio/file/Path/Misc.java tests into java/nio/file/Path/PathOps.java

Changes: https://git.openjdk.org/jdk/pull/15572/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315485
  Stats: 154 lines in 2 files changed: 63 ins; 88 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15572/head:pull/15572

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

From msheppar at openjdk.org  Tue Sep  5 22:25:39 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 5 Sep 2023 22:25:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <Rr1FNFUPl3iuZz7bCujdhv3jOHvKx_ruMOE-55E_xOM=.3eca3dc7-aa3b-481c-8b16-cf16363e3c51@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

> From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't.
> 
> I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function.
> 
> I also think it is too obscure that functions with _Test_ in the name prepend the extra test options, and those without _Test_ don't, so I'd like to get rid of that convention.
> 
> I wouldn't be opposed to a change that:
> 
>     * Keeps the `createJavaProcessBuilder` name
> 
>     * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> 
>     * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> 
>     * Removes `createTestJava`
> 
>     * Removes `executeTestJava`

I think @stefank made a reasonable suggestion which was endorsed by @AlanBateman 

which would remove the misconception hurdle

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707391042

From erikj at openjdk.org  Tue Sep  5 22:58:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Sep 2023 22:58:17 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
Message-ID: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>

There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.

It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

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

Commit messages:
 - JDK-8267174

Changes: https://git.openjdk.org/jdk/pull/15573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8267174
  Stats: 1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod
  Patch: https://git.openjdk.org/jdk/pull/15573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15573/head:pull/15573

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

From cjplummer at openjdk.org  Tue Sep  5 23:15:36 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Sep 2023 23:15:36 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707426607

From jjg at openjdk.org  Tue Sep  5 23:18:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 5 Sep 2023 23:18:39 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup

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

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612069262

From valeriep at openjdk.org  Tue Sep  5 23:37:37 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 5 Sep 2023 23:37:37 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <aVRmvg-3pOxfnv6lMg93x2owljLiQwkjkEAPkLoomZg=.d714bb29-e4c4-4dd1-bb4f-21f38175294b@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Security area looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612089791

From bpb at openjdk.org  Wed Sep  6 02:33:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Sep 2023 02:33:49 GMT
Subject: RFR: 8315485: (fs) Move java/nio/file/Path/Misc.java tests into
 java/nio/file/Path/PathOps.java
In-Reply-To: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
References: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
Message-ID: <jOwmS1BVN86K9mDY6lj75vrgOqXCuVKfoH-jy_uN8-Y=.46b4c80a-75d7-458c-9d98-8e04a3a41a69@github.com>

On Tue, 5 Sep 2023 21:58:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In the `java/nio/file/Path` tests, add to `PathOps` tests equivalent to those in `Misc` and then remove the latter.

Moving to draft pending revision.

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

PR Comment: https://git.openjdk.org/jdk/pull/15572#issuecomment-1707563514

From alanb at openjdk.org  Wed Sep  6 07:53:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Sep 2023 07:53:36 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>
Message-ID: <fOmBMZKLj2AJTcJh3JfjZbZRF_BtOusIx3tDlHq5QhE=.422d0570-2764-40ac-b224-a79c54396ece@github.com>

On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup

The IBM double byte charsets were re-implemented in JDK 7. I think the old implementations moved to the test tree so it could be used to test the new/replacement implementations.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707845577

From jvernee at openjdk.org  Wed Sep  6 10:04:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:04:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v11]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <BaueIi9igFN67aRBrbqg_HLf37HMirB3Ecr-IZOJPjA=.6d469528-fdd5-424b-9fb1-1f4da4f439e9@github.com>

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

  Fix typo in doc
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/de3e7479..5e439da8

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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

From jvernee at openjdk.org  Wed Sep  6 10:04:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:04:38 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
 <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
Message-ID: <Vn684JdyfXwiOcS7wLbe16vP1kxx0jZvV5FGdsb565M=.ce9ac2e0-1907-4f9e-a254-ff8fe98520b1@github.com>

On Tue, 5 Sep 2023 21:10:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8315096: Allowed access modes in memory segment should depend on layout alignment
>>    
>>    Reviewed-by: psandoz
>>  - Add missing @implSpec to AddressLayout
>>    
>>    Reviewed-by: pminborg
>>  - Fix misc typos in FFM API javadoc
>>    
>>    Reviewed-by: jvernee
>>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two)
>>    
>>    Reviewed-by: pminborg
>>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle
>>    
>>    Reviewed-by: jvernee
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 443:
> 
>> 441:      *
>> 442:      * {@snippet lang = "java":
>> 443:      * offset = this.offsetHandle(P).invokeExact(B, I1, I2, ... In);
> 
> Suggestion:
> 
>      * O = this.offsetHandle(P).invokeExact(B, I1, I2, ... In);
> 
> To align with the use of `O` later on.

Good catch. The `O` later on was added separately, hence they are out of sync.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317041205

From jvernee at openjdk.org  Wed Sep  6 10:04:40 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:04:40 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v11]
In-Reply-To: <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
 <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
Message-ID: <ErzgaADyQEqX7QJAF3gd8ip37QCvmI6W4L_nf3f964E=.efcd47c3-a66c-44d1-8b0e-c7fe7f623635@github.com>

On Tue, 5 Sep 2023 21:56:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in doc
>>   
>>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8027:
> 
>> 8025:      * @since 19
>> 8026:      */
>> 8027:     @PreviewFeature(feature=PreviewFeature.Feature.FOREIGN)
> 
> Unused import to `PreviewFeature`, and possibly others too.

Thanks. I did a sweep of the foreign packages and there don't seem to be any other uses. There were also some other unused imports in this file that I'll remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317045735

From jvernee at openjdk.org  Wed Sep  6 10:48:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:48:06 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v12]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <EIalWkW_AC5I4-jwbhpPmVHlmKOPQxS3LRlyuq6Kto0=.975a920e-630f-4a8b-80d9-2514c11f8a90@github.com>

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

  Paul's review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/5e439da8..afcfa2b5

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

  Stats: 15 lines in 5 files changed: 0 ins; 10 del; 5 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

From mdoerr at openjdk.org  Wed Sep  6 10:48:52 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 6 Sep 2023 10:48:52 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v11]
In-Reply-To: <BaueIi9igFN67aRBrbqg_HLf37HMirB3Ecr-IZOJPjA=.6d469528-fdd5-424b-9fb1-1f4da4f439e9@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <BaueIi9igFN67aRBrbqg_HLf37HMirB3Ecr-IZOJPjA=.6d469528-fdd5-424b-9fb1-1f4da4f439e9@github.com>
Message-ID: <SQTApVpYmnwn02YmZodaC61oXrGnzTEFKnMXPLpgC9Y=.072ee4a5-6279-4bc7-af0e-e2702af64689@github.com>

On Wed, 6 Sep 2023 10:04:35 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Fix typo in doc
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Please adapt the new `LinuxPPC64Linker` when merging:

diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java b/src/java.base/share/classes/jdk/inter
nal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
index 150687d4078..7cf2d524bff 100644
--- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
+++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
@@ -27,15 +27,22 @@
 
 import jdk.internal.foreign.abi.AbstractLinker;
 import jdk.internal.foreign.abi.LinkerOptions;
+import jdk.internal.foreign.abi.SharedUtils;
 import jdk.internal.foreign.abi.ppc64.CallArranger;
 
 import java.lang.foreign.FunctionDescriptor;
+import java.lang.foreign.MemoryLayout;
+import java.lang.foreign.ValueLayout;
 import java.lang.invoke.MethodHandle;
 import java.lang.invoke.MethodType;
 import java.nio.ByteOrder;
+import java.util.Map;
 
 public final class LinuxPPC64Linker extends AbstractLinker {
 
+    static final Map<String, MemoryLayout> CANONICAL_LAYOUTS =
+        SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT);
+
     public static LinuxPPC64Linker getInstance() {
         final class Holder {
             private static final LinuxPPC64Linker INSTANCE = new LinuxPPC64Linker();
@@ -62,4 +69,9 @@ protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescrip
     protected ByteOrder linkerByteOrder() {
         return ByteOrder.BIG_ENDIAN;
     }
+
+    @Override
+    public Map<String, MemoryLayout> canonicalLayouts() {
+        return CANONICAL_LAYOUTS;
+    }
 }

The `test/jdk/java/foreign` tests have passed on both, linux PPC64 and PPC64le.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1708107829

From jvernee at openjdk.org  Wed Sep  6 10:54:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:54:46 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v11]
In-Reply-To: <SQTApVpYmnwn02YmZodaC61oXrGnzTEFKnMXPLpgC9Y=.072ee4a5-6279-4bc7-af0e-e2702af64689@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <BaueIi9igFN67aRBrbqg_HLf37HMirB3Ecr-IZOJPjA=.6d469528-fdd5-424b-9fb1-1f4da4f439e9@github.com>
 <SQTApVpYmnwn02YmZodaC61oXrGnzTEFKnMXPLpgC9Y=.072ee4a5-6279-4bc7-af0e-e2702af64689@github.com>
Message-ID: <csav_r_69s-OlGkyZq8XDpOOhq6JhqSInp-TBPGlh2w=.08be03d6-5af6-4b03-8e17-8cd5d6a0f6b3@github.com>

On Wed, 6 Sep 2023 10:46:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in doc
>>   
>>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>
> Please adapt the new `LinuxPPC64Linker` when merging:
> 
> diff --git a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java b/src/java.base/share/classes/jdk/inter
> nal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
> index 150687d4078..7cf2d524bff 100644
> --- a/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
> +++ b/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64Linker.java
> @@ -27,15 +27,22 @@
>  
>  import jdk.internal.foreign.abi.AbstractLinker;
>  import jdk.internal.foreign.abi.LinkerOptions;
> +import jdk.internal.foreign.abi.SharedUtils;
>  import jdk.internal.foreign.abi.ppc64.CallArranger;
>  
>  import java.lang.foreign.FunctionDescriptor;
> +import java.lang.foreign.MemoryLayout;
> +import java.lang.foreign.ValueLayout;
>  import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.MethodType;
>  import java.nio.ByteOrder;
> +import java.util.Map;
>  
>  public final class LinuxPPC64Linker extends AbstractLinker {
>  
> +    static final Map<String, MemoryLayout> CANONICAL_LAYOUTS =
> +        SharedUtils.canonicalLayouts(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_INT);
> +
>      public static LinuxPPC64Linker getInstance() {
>          final class Holder {
>              private static final LinuxPPC64Linker INSTANCE = new LinuxPPC64Linker();
> @@ -62,4 +69,9 @@ protected UpcallStubFactory arrangeUpcall(MethodType targetType, FunctionDescrip
>      protected ByteOrder linkerByteOrder() {
>          return ByteOrder.BIG_ENDIAN;
>      }
> +
> +    @Override
> +    public Map<String, MemoryLayout> canonicalLayouts() {
> +        return CANONICAL_LAYOUTS;
> +    }
>  }
> 
> The `test/jdk/java/foreign` tests have passed on both, linux PPC64 and PPC64le.

@TheRealMDoerr Thanks for the patch, will include it.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1708114403

From jvernee at openjdk.org  Wed Sep  6 10:54:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 10:54:48 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
 <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
Message-ID: <dcSQRs4l2dXOiYxWvfxKqgpJbyOsTxKtYFShCU0wTlI=.a3e04b95-4a7c-4442-afd6-e8d7dc333494@github.com>

On Tue, 5 Sep 2023 21:01:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8315096: Allowed access modes in memory segment should depend on layout alignment
>>    
>>    Reviewed-by: psandoz
>>  - Add missing @implSpec to AddressLayout
>>    
>>    Reviewed-by: pminborg
>>  - Fix misc typos in FFM API javadoc
>>    
>>    Reviewed-by: jvernee
>>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two)
>>    
>>    Reviewed-by: pminborg
>>  - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle
>>    
>>    Reviewed-by: jvernee
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 152:
> 
>> 150:  * <p>
>> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided
>> 152:  * here will assume these platform-dependent mappings):
> 
> Up to you, but it might be useful to link to the ABI specifications if the links are considered stable.

There is this: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf I'm not sure how stable this is. I don't think that website is an authoritative source. (at least, not to the degree it is for e.g. AArch64: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#595homogeneous-aggregates). Note also that is a draft. I think the final version is paywalled.

Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI")

Then people can google for themselves and find it. For instance, [this SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo with a more up to date version: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317100703

From jvernee at openjdk.org  Wed Sep  6 11:20:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 11:20:18 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v13]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <97cANIvE2FMHvs_WDQ4BXFxfnjgtJ7fLfbLfM_aCONA=.a832d87f-5847-492b-9843-2b88346090f1@github.com>

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

 - PPC linker changes
 - Merge branch 'master' into JEP22
 - Paul's review comments
 - Fix typo in doc
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - 8315096: Allowed access modes in memory segment should depend on layout alignment
   
   Reviewed-by: psandoz
 - Add missing @implSpec to AddressLayout
   
   Reviewed-by: pminborg
 - Fix misc typos in FFM API javadoc
   
   Reviewed-by: jvernee
 - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle (part two)
   
   Reviewed-by: pminborg
 - Clarify javadoc w.r.t. exceptions thrown by a memory access var handle
   
   Reviewed-by: jvernee
 - remove unsupported linker test
 - ... and 24 more: https://git.openjdk.org/jdk/compare/62a953f4...b8bb791f

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=12
  Stats: 3176 lines in 238 files changed: 1480 ins; 951 del; 745 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

From dfuchs at openjdk.org  Wed Sep  6 11:54:38 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 6 Sep 2023 11:54:38 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <N2aDwFlX5JMFggsLteErbSyA6N4JJpAJcXSYurnNCQk=.b0556411-442f-465e-86da-705f04a63ceb@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

jmx, jndi, and net changes LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613147541

From jvernee at openjdk.org  Wed Sep  6 12:01:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Sep 2023 12:01:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v14]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <GIBSx0N1elXRIKgCxATGmlPuEXF7ALTGQSeIKpQkWG8=.da8643eb-cf65-4add-8041-d438e37731c4@github.com>

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

  remove reference to allocateArray

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/b8bb791f..52df58f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=12-13

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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

From aivanov at openjdk.org  Wed Sep  6 13:09:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Sep 2023 13:09:38 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <Nm6Ho3fcyVeur-ccqrwdrgo0N_E0YFQzHa1FnaqqVI8=.690a5255-fa88-40d1-ac4a-59b8b2b03873@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Client changes look good.

I've looked through all the files, other files look good too.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613295743

From bpb at openjdk.org  Wed Sep  6 15:33:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Sep 2023 15:33:33 GMT
Subject: RFR: 8315485: (fs) Move java/nio/file/Path/Misc.java tests into
 java/nio/file/Path/PathOps.java [v2]
In-Reply-To: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
References: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
Message-ID: <7XW-cxWPmJr_5SRRrQ4RJY5UZ_pSS8j2K7WZAYO1Fas=.dd4fff03-7bd1-4f8c-8c68-32bf81aaa14d@github.com>

> In the `java/nio/file/Path` tests, add to `PathOps` tests equivalent to those in `Misc` and then remove the latter.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8315485: Fix whitespace errors
 - 8315485: Refactor equals()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15572/files
  - new: https://git.openjdk.org/jdk/pull/15572/files/e5dc8a0f..2c4b9501

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

  Stats: 34 lines in 1 file changed: 9 ins; 14 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15572/head:pull/15572

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

From tprinzing at openjdk.org  Wed Sep  6 15:57:41 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 6 Sep 2023 15:57:41 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
 <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
 <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>
Message-ID: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>

On Tue, 22 Aug 2023 07:31:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
> 
> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.

I think it's useful if trying to trace the calls (i.e. set to 0ms).  Apparently the security manager was being used for that by some.

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1708657617

From iris at openjdk.org  Wed Sep  6 16:02:41 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 6 Sep 2023 16:02:41 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <apHME2YL4_kpuLd0FXFapVoPEswuBVLBYVzTDihni28=.3d5ef23e-2f8d-42b0-a8ef-28f43b5bcb81@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Thanks for fixing!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613704179

From psandoz at openjdk.org  Wed Sep  6 16:06:47 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 6 Sep 2023 16:06:47 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <dcSQRs4l2dXOiYxWvfxKqgpJbyOsTxKtYFShCU0wTlI=.a3e04b95-4a7c-4442-afd6-e8d7dc333494@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
 <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
 <dcSQRs4l2dXOiYxWvfxKqgpJbyOsTxKtYFShCU0wTlI=.a3e04b95-4a7c-4442-afd6-e8d7dc333494@github.com>
Message-ID: <Ni_48mlxlsbH4dQSuD8JJQvWmp6kI0oyEeLf7hEvO0s=.7887abd1-f0ae-42f6-a32b-beb485edf871@github.com>

On Wed, 6 Sep 2023 10:50:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 152:
>> 
>>> 150:  * <p>
>>> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 (all the examples provided
>>> 152:  * here will assume these platform-dependent mappings):
>> 
>> Up to you, but it might be useful to link to the ABI specifications if the links are considered stable.
>
> [This SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo that seems to have the latest version: https://gitlab.com/x86-psABIs/x86-64-ABI But, I'm not sure how stable that is, or if that's an authoritative source.
> 
> Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI") Then people can google for themselves and find it.

Yeah, its hard to find the official and latest version. Referring to the full title will help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1317517319

From erikj at openjdk.org  Wed Sep  6 16:09:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Sep 2023 16:09:41 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
Message-ID: <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>

On Tue, 5 Sep 2023 23:12:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.

Do you think I should revert them?

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708676439

From bpb at openjdk.org  Wed Sep  6 16:24:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Sep 2023 16:24:45 GMT
Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for
 CharSequence [v4]
In-Reply-To: <LQPK7p4sUWNArkm4LthCIcBMTgUEXu2iYdAspoj8rQ8=.f26391e4-7a53-4684-a8bd-45a884346e72@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <LQPK7p4sUWNArkm4LthCIcBMTgUEXu2iYdAspoj8rQ8=.f26391e4-7a53-4684-a8bd-45a884346e72@github.com>
Message-ID: <hs-2uq1bv5b4OhB1NnMmA_fiEQ00HxnSrbxbVEMXNSY=.3671f76f-6c18-414a-9cc7-80bc37c12cf9@github.com>

On Fri, 14 Jul 2023 15:54:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4860681: Heap and direct buffer specializations

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1708705183

From lkorinth at openjdk.org  Wed Sep  6 16:24:45 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 6 Sep 2023 16:24:45 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <cAbrAW1-EzSMgJMLOD90ZAgUNU7LcbYF3GYZKPp7sgw=.5f71207b-0641-4b7d-9033-d35e25fd90ef@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I think you are missing the point. If you take a look at [the parent bug of the sub task](https://bugs.openjdk.org/browse/JDK-8314823) you can see that the problem described is *not* that people are using `createTestJvm` in error. The problem is that they are (or possibly are) using `createJavaProcessBuilder` in error. Thus renaming `createTestJvm` might help a little at most for this specific problem. Renaming `createJavaProcessBuilder` most probably helps *more*. I guess the alternative of forcing the user to make a choice using an enum value will help even more.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1708705105

From cjplummer at openjdk.org  Wed Sep  6 16:52:42 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 6 Sep 2023 16:52:42 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
 <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
Message-ID: <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>

On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.
> 
> Do you think I should revert them?

I'm not sure. I think you need to consult someone with expertise in this area.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708757719

From alanb at openjdk.org  Wed Sep  6 17:45:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Sep 2023 17:45:41 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
 <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
 <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>
Message-ID: <M3p5gLpJ1VZuXjRBL3DVy6aVVpw-iAyuAJGxwWLYVcY=.40e98cad-b75c-4caa-b41f-d8bd63c5a9ba@github.com>

On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.
> 
> Do you think I should revert them?

They are test classes now. If someone does want to copy them into their own repo then I assume they can take it from an old repo, maybe from when the "hat" tool existed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708828207

From alanb at openjdk.org  Thu Sep  7 06:48:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Sep 2023 06:48:40 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
 <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
 <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>
 <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
Message-ID: <mTCrMQuFpKqzuI1W25R273DSJdYuMY6hfZGci6KFQLI=.39618118-57d3-4575-812f-e1660ca41166@github.com>

On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> I think it's useful if trying to trace the calls (i.e. set to 0ms). Apparently the security manager was being used for that by some.

The SM isn't called once connected so I don't think anyone could have every done that. Yes, you could set the threshold to 0ms to emit event for every read/write but I wonder how useful that would be, maybe I/O stats would be more interesting.

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1709568576

From jvernee at openjdk.org  Thu Sep  7 11:39:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 11:39:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v15]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <Eu_t8ufOvBenFc2FXkC7ERRTDO1WgGWFZg1gO7EMPJk=.82ac01f0-319d-4132-9ea6-96c9c57ff435@github.com>

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

 - add name of SysV ABI
 - Fix javadoc issues in MemorySegment::copy
   
   Reviewed-by: jvernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/52df58f5..a48a77bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=13-14

  Stats: 10 lines in 2 files changed: 3 ins; 0 del; 7 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

From jvernee at openjdk.org  Thu Sep  7 11:39:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 11:39:32 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v10]
In-Reply-To: <Ni_48mlxlsbH4dQSuD8JJQvWmp6kI0oyEeLf7hEvO0s=.7887abd1-f0ae-42f6-a32b-beb485edf871@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <f1zzRmgoYuMhuJfWyVUq6vlldd1wI4bR--IodOsstp4=.8d471ae5-8a0e-4afa-b57d-d335df07aad0@github.com>
 <Ue1_u6BdTYSK02COUzo3cnVoo4ujOqPzZx-5kQIL2lo=.ff6b93c0-b744-4e62-9aff-6a452fc23d91@github.com>
 <dcSQRs4l2dXOiYxWvfxKqgpJbyOsTxKtYFShCU0wTlI=.a3e04b95-4a7c-4442-afd6-e8d7dc333494@github.com>
 <Ni_48mlxlsbH4dQSuD8JJQvWmp6kI0oyEeLf7hEvO0s=.7887abd1-f0ae-42f6-a32b-beb485edf871@github.com>
Message-ID: <Gk6sFAlGVJ_NCq9mal9u7w22BLaQFiNBEd--BiZIxaE=.b536254b-504d-4023-bff1-f038f9cafb25@github.com>

On Wed, 6 Sep 2023 16:03:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> [This SO question](https://stackoverflow.com/a/40348010) points to a gitlab repo that seems to have the latest version: https://gitlab.com/x86-psABIs/x86-64-ABI But, I'm not sure how stable that is, or if that's an authoritative source.
>> 
>> Alternatively, we could refer to the name only: "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (or "x86-64 psABI") Then people can google for themselves and find it.
>
> Yeah, its hard to find the official and latest version. Referring to the full title will help.

I've added the name now: https://github.com/openjdk/jdk/pull/15103/commits/a48a77bcdadda65a81ad30abf00e6da46a56b933

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1318472039

From jvernee at openjdk.org  Thu Sep  7 13:07:50 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 13:07:50 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v16]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <r28VnGGtbD8ZND0nZ13HxACxrsuYoHWObtYD5CSltcA=.9e6ac1b5-c144-4e14-8ef9-6c27b1a98aee@github.com>

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

  Add support for sliced allocation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/a48a77bc..55296527

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=14-15

  Stats: 539 lines in 9 files changed: 413 ins; 56 del; 70 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

From jvernee at openjdk.org  Thu Sep  7 13:08:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 13:08:15 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v15]
In-Reply-To: <Eu_t8ufOvBenFc2FXkC7ERRTDO1WgGWFZg1gO7EMPJk=.82ac01f0-319d-4132-9ea6-96c9c57ff435@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <Eu_t8ufOvBenFc2FXkC7ERRTDO1WgGWFZg1gO7EMPJk=.82ac01f0-319d-4132-9ea6-96c9c57ff435@github.com>
Message-ID: <Cv8IgofLHB1NNJSQ6ctlMYw_2X9niy9lKlNZYfAbBm0=.7983deb9-d800-4007-abf6-fecdfd98271d@github.com>

On Thu, 7 Sep 2023 11:39:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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:
> 
>  - add name of SysV ABI
>  - Fix javadoc issues in MemorySegment::copy
>    
>    Reviewed-by: jvernee

After discussing with Maurizio, I've added one more non-trivial change to this patch, brought over from the panama-foreign repo. This adds a new `SegmentAllocator::allocateFrom` overload which accepts a MemorySegment as an initializer. See the original PR: https://github.com/openjdk/panama-foreign/pull/878

The commit I've added also includes the changes from https://github.com/openjdk/panama-foreign/pull/855 which were required by the first patch. I had to massage the code a bit since the javadoc in the mainline slightly deviates from the one in the panama-foreign repo.

Please take a look at the changes here: https://github.com/openjdk/jdk/pull/15103/commits/55296527a029b80dd78a7d1aecb429e793d7d32e

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1710117041

From alanb at openjdk.org  Thu Sep  7 16:07:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Sep 2023 16:07:42 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
Message-ID: <T0ckSTmr55Wk6ENNZM4rLgj8Ca4METqhGZgR3WJq5ww=.24200d1a-d13a-480f-b66f-1d546100bec5@github.com>

On Tue, 5 Sep 2023 17:05:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Address reviewer comments

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1050:

> 1048:             else if (!sourceAttrs.isSymbolicLink() || flags.followLinks) {
> 1049:                 // ensure source can be moved
> 1050:                 try {

This is copy rather than move but I think R_OK is correct, at least for regular files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318827863

From alanb at openjdk.org  Thu Sep  7 16:11:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Sep 2023 16:11:41 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
Message-ID: <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>

On Tue, 5 Sep 2023 17:05:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Address reviewer comments

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:

> 918:                 // ensure source can be moved
> 919:                 try {
> 920:                     access(source, R_OK|W_OK);

I wonder this should be changed to R_OK and done after the rename attempt has failed. I think that would make it consistent with the copy case (as move falls back to a copy when rename fails).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318832116

From bpb at openjdk.org  Thu Sep  7 16:14:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Sep 2023 16:14:43 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
 <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
Message-ID: <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>

On Thu, 7 Sep 2023 16:08:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Address reviewer comments
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:
> 
>> 918:                 // ensure source can be moved
>> 919:                 try {
>> 920:                     access(source, R_OK|W_OK);
> 
> I wonder this should be changed to R_OK and done after the rename attempt has failed. I think that would make it consistent with the copy case (as move falls back to a copy when rename fails).

But the existing target would be deleted after line 928 before rename() is called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318837705

From alanb at openjdk.org  Thu Sep  7 16:18:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Sep 2023 16:18:43 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
 <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
 <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>
Message-ID: <XdhgfSCC6tjOov73qwTPH-z4_I_FZSHUjgo6GSEMBm0=.b85df435-4c04-4abf-b8b6-4357ed4fcafb@github.com>

On Thu, 7 Sep 2023 16:12:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 920:
>> 
>>> 918:                 // ensure source can be moved
>>> 919:                 try {
>>> 920:                     access(source, R_OK|W_OK);
>> 
>> I wonder this should be changed to R_OK and done after the rename attempt has failed. I think that would make it consistent with the copy case (as move falls back to a copy when rename fails).
>
> But the existing target would be deleted after line 928 before rename() is called.

Okay, you're right but I'm not 100% sure that the mode is right, I assumed it would be R_OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318846345

From bpb at openjdk.org  Thu Sep  7 16:18:45 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Sep 2023 16:18:45 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <XdhgfSCC6tjOov73qwTPH-z4_I_FZSHUjgo6GSEMBm0=.b85df435-4c04-4abf-b8b6-4357ed4fcafb@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
 <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
 <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>
 <XdhgfSCC6tjOov73qwTPH-z4_I_FZSHUjgo6GSEMBm0=.b85df435-4c04-4abf-b8b6-4357ed4fcafb@github.com>
Message-ID: <GbXgncF_1H8FDVnaIhUd9hOJSM2sGtYhQUzhUPX1z90=.c6de1bf1-84a6-461e-bccf-4aad40940876@github.com>

On Thu, 7 Sep 2023 16:14:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> But the existing target would be deleted after line 928 before rename() is called.
>
> Okay, you're right but I'm not 100% sure that the mode is right, I assumed it would be R_OK.

I will investigate the mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318848066

From jvernee at openjdk.org  Thu Sep  7 16:26:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 16:26:48 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v17]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <Hk2MzyANIFiru1Pey4OJSeDswhyA5F3GsYdXGFBVX2M=.4b1111b8-7f6f-4df0-8517-d2ce3e5b6eac@github.com>

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

  Split long throws clauses in `MemorySegment` javadoc
  
  Reviewed-by: jvernee

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/55296527..2f50adbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=15-16

  Stats: 41 lines in 1 file changed: 3 ins; 0 del; 38 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

From alanb at openjdk.org  Thu Sep  7 16:28:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Sep 2023 16:28:41 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <GbXgncF_1H8FDVnaIhUd9hOJSM2sGtYhQUzhUPX1z90=.c6de1bf1-84a6-461e-bccf-4aad40940876@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
 <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
 <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>
 <XdhgfSCC6tjOov73qwTPH-z4_I_FZSHUjgo6GSEMBm0=.b85df435-4c04-4abf-b8b6-4357ed4fcafb@github.com>
 <GbXgncF_1H8FDVnaIhUd9hOJSM2sGtYhQUzhUPX1z90=.c6de1bf1-84a6-461e-bccf-4aad40940876@github.com>
Message-ID: <9p1BBSaTIuRd9GDfVMvOGF93ruy_AiK6O-53WpmzZIU=.944032e8-b353-45c0-be69-00b2d300f5a9@github.com>

On Thu, 7 Sep 2023 16:16:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I will investigate the mode.

Okay. The change to copy looks okay, as does the change to the helper for cross-provider copy/move, it's just the move in the Unix provider where I can't say for sure without doing some experiments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318858424

From bpb at openjdk.org  Thu Sep  7 16:31:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Sep 2023 16:31:43 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v3]
In-Reply-To: <9p1BBSaTIuRd9GDfVMvOGF93ruy_AiK6O-53WpmzZIU=.944032e8-b353-45c0-be69-00b2d300f5a9@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <Cco9vJR7LUth7MqUM3L0OmSiYlKVoiF_ojmBfRrGslk=.c4cadb17-6a83-424e-9fbb-fb2c384fd6b6@github.com>
 <Z3y_M2ok-Ddr4KyPNkTWonbUY-LYBF3RRRYkSpRlWxI=.98891fa1-12f6-4417-86ff-0a86afb2ecfd@github.com>
 <VP9Oh7UyT6jl-m2FKFXZcuWBAeljriXS5pCAbSef9WI=.8d3c2442-2d14-4db4-95bc-4f2200541187@github.com>
 <XdhgfSCC6tjOov73qwTPH-z4_I_FZSHUjgo6GSEMBm0=.b85df435-4c04-4abf-b8b6-4357ed4fcafb@github.com>
 <GbXgncF_1H8FDVnaIhUd9hOJSM2sGtYhQUzhUPX1z90=.c6de1bf1-84a6-461e-bccf-4aad40940876@github.com>
 <9p1BBSaTIuRd9GDfVMvOGF93ruy_AiK6O-53WpmzZIU=.944032e8-b353-45c0-be69-00b2d300f5a9@github.com>
Message-ID: <5jvfSDPRw1SOBWe885_A_QXNV12gkVA1UApltqBSeYc=.b66ad1d5-01a7-4e37-b536-98ef6dd51d4a@github.com>

On Thu, 7 Sep 2023 16:25:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I will investigate the mode.
>
>> I will investigate the mode.
> 
> Okay. The change to copy looks okay, as does the change to the helper for cross-provider copy/move, it's just the move in the Unix provider where I can't say for sure without doing some experiments.

The `W_OK` is not needed here as you suggested. With only `R_OK` being set, the proposed patch does not delete the existing target, but the mainline does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1318862197

From bpb at openjdk.org  Thu Sep  7 16:52:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Sep 2023 16:52:10 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v4]
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <FW6vQ0RbzRRyrDwD-IJqXzZMhhJ2CorTWNbLebEJchk=.29442036-6ad7-4961-b01f-610d304f5dd5@github.com>

> Check that the source is readable before deleting the destination.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8073061: R_OK|W_OK -> R_OK in move source access check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15501/files
  - new: https://git.openjdk.org/jdk/pull/15501/files/e226096d..65009624

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

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

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

From jvernee at openjdk.org  Thu Sep  7 19:01:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Sep 2023 19:01:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v18]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <lkKKtzVOKHNnAGRaXCV3Z56MwTMkkWqw_M6HtZFLO7E=.05eae788-9df5-4a2e-a0bc-01a44d15d6e4@github.com>

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

  add code snippet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/2f50adbf..86a7e227

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=16-17

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 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

From tprinzing at openjdk.org  Thu Sep  7 21:50:17 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 7 Sep 2023 21:50:17 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v5]
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <XQx22AT3AFHjoa-7vY9zjqpgU5mPtFYfu0WANDvW-ng=.2737cfa2-8fbb-4594-a3d5-b4e1e014c383@github.com>

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  More changes from review:
  
  I didn't like the name of the helper method 'checkForCommit' because it
  doesn't indicate that it might commit the event.  I also don't like
  'commitEvent' because it might not.  Since JFR events are sort of like a
  queue I went with a name from collections and called it 'offer' so using
  it is something like 'SocketReadEvent.offer(...)' which seems like it
  gets the idea across better.  Also improved the javadoc for it.
  
  Removed the comments about being instrumented by JFR in
  Socket.SocketInputStream and Socket.SocketOutputStream.
  
  I went ahead and moved the event commiting out of the finally block so
  that we don't emit events when the read/write did not actually happen.
  The bugid JDK-8310979 will be used to determine if more should be done
  in this area.
  
  The implRead and implWrite were moved up with the other support methods
  for read/write.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14342/files
  - new: https://git.openjdk.org/jdk/pull/14342/files/d6f7df72..9fa27459

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

  Stats: 151 lines in 5 files changed: 57 ins; 81 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

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

From tprinzing at openjdk.org  Thu Sep  7 21:57:40 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 7 Sep 2023 21:57:40 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <dHY_YlyH_mN3TaYO-ZzBtyqTEAs7vSlc8_L8_MsGXgU=.e071811b-a84d-4c31-89b6-3cadc4048ef3@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
 <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
 <dHY_YlyH_mN3TaYO-ZzBtyqTEAs7vSlc8_L8_MsGXgU=.e071811b-a84d-4c31-89b6-3cadc4048ef3@github.com>
Message-ID: <fbRpcgvGTiIi3_dpDxEJQhdlfP8Dz87QMpG3cchORJA=.9d6188c0-b364-403c-aad0-2488ff167764@github.com>

On Tue, 22 Aug 2023 07:18:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 1133:
>> 
>>> 1131:                 return parent.getSoTimeout();
>>> 1132:             } catch (Throwable t) {
>>> 1133:                 // ignored - avoiding exceptions in jfr event data gathering
>> 
>> This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away.
>
> Were you able to find out what the timeout is used for?

No.  I think it's a relic from the distant past though.  I think the timeout field should be removed.  It's not used on SocketChannel at all, and it doesn't seem useful on Socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1319152153

From duke at openjdk.org  Fri Sep  8 11:24:48 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 8 Sep 2023 11:24:48 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v16]
In-Reply-To: <r28VnGGtbD8ZND0nZ13HxACxrsuYoHWObtYD5CSltcA=.9e6ac1b5-c144-4e14-8ef9-6c27b1a98aee@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <r28VnGGtbD8ZND0nZ13HxACxrsuYoHWObtYD5CSltcA=.9e6ac1b5-c144-4e14-8ef9-6c27b1a98aee@github.com>
Message-ID: <XYW65ND7QEt5Bv4TSQ8ktBs_GnRmIBIANoKYpWyBAxU=.f7ffb239-0160-418a-a52a-efc55a03f823@github.com>

On Thu, 7 Sep 2023 13:07:50 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Add support for sliced allocation

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 154:

> 152:             return UNSAFE.allocateMemory(size);
> 153:         } catch (IllegalArgumentException ex) {
> 154:             throw new OutOfMemoryError();

`OutOfMemoryError` should?be?updated to?have the?`Throwable`?accepting constructor?overloads, so?that this?can?include the?cause:
Suggestion:

            throw new OutOfMemoryError(ex);


See?also: https://github.com/openjdk/panama-foreign/pull/855#discussion_r1285058300

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1319732046

From jvernee at openjdk.org  Fri Sep  8 14:35:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Sep 2023 14:35:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v19]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <xMBBhGX5Vo6reK_l5YUzu70uBTGg8StVPgsLuxm2EkI=.121d3664-7253-4759-9a00-1cdc8ee91caf@github.com>

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

 - Merge branch 'master' into JEP22
 - add code snippet
 - Split long throws clauses in `MemorySegment` javadoc
   
   Reviewed-by: jvernee
 - Add support for sliced allocation
 - add name of SysV ABI
 - Fix javadoc issues in MemorySegment::copy
   
   Reviewed-by: jvernee
 - remove reference to allocateArray
 - PPC linker changes
 - Merge branch 'master' into JEP22
 - Paul's review comments
 - ... and 31 more: https://git.openjdk.org/jdk/compare/e409d07a...dbf3eec6

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=18
  Stats: 3753 lines in 244 files changed: 1897 ins; 1000 del; 856 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

From jvernee at openjdk.org  Fri Sep  8 14:40:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Sep 2023 14:40:47 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v16]
In-Reply-To: <XYW65ND7QEt5Bv4TSQ8ktBs_GnRmIBIANoKYpWyBAxU=.f7ffb239-0160-418a-a52a-efc55a03f823@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <r28VnGGtbD8ZND0nZ13HxACxrsuYoHWObtYD5CSltcA=.9e6ac1b5-c144-4e14-8ef9-6c27b1a98aee@github.com>
 <XYW65ND7QEt5Bv4TSQ8ktBs_GnRmIBIANoKYpWyBAxU=.f7ffb239-0160-418a-a52a-efc55a03f823@github.com>
Message-ID: <MZqcyA_I13COgnRLdW28c6P2BxVn85CPopeysXjgb_s=.60152f85-c9ab-496e-b0a5-ad18cd202c33@github.com>

On Fri, 8 Sep 2023 11:20:39 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for sliced allocation
>
> src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 154:
> 
>> 152:             return UNSAFE.allocateMemory(size);
>> 153:         } catch (IllegalArgumentException ex) {
>> 154:             throw new OutOfMemoryError();
> 
> `OutOfMemoryError` should?be?updated to?have the?`Throwable`?accepting constructor?overloads, so?that this?can?include the?cause:
> Suggestion:
> 
>             throw new OutOfMemoryError(ex);
> 
> 
> See?also: https://github.com/openjdk/panama-foreign/pull/855#discussion_r1285058300

I think enhancing `OutOfMemoryError` is a discussion to be had separately. Not as a part of this JEP.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1319957862

From lancea at openjdk.org  Sat Sep  9 14:41:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 9 Sep 2023 14:41:12 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
Message-ID: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>

Please review this PR which improves the Zip64 extra header validation:

- Throw a ZipException If the extra len field is 0 and :
-- size, csize, or loc offset are not set to 0xFFFFFFFF
-- disk starting number is not set to 0xFFFF

- We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header

Mach5 tiers 1-3 are clean

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

Commit messages:
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

Changes: https://git.openjdk.org/jdk/pull/15650/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314891
  Stats: 544 lines in 3 files changed: 513 ins; 7 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From dholmes at openjdk.org  Mon Sep 11 07:15:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Sep 2023 07:15:45 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <-l07QgwUIOOMsXw9SniuLk856xxeIs8v6lwe8SWO_oI=.7c375b23-9f35-4d0d-a7bb-5fe513edb1d5@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good. I have often pointed out that the CPE was not relevant for test files but ...

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619274864

From ihse at openjdk.org  Mon Sep 11 10:37:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Sep 2023 10:37:45 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <PgnNOjnEriF0t6VBP3CIbu8HSSLcD2FQV1HgQHOgcyc=.65e4127f-2449-4fa2-b0a1-531767e43f21@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good to me. Thanks for doing this cleanup!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619669362

From jvernee at openjdk.org  Mon Sep 11 15:37:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 11 Sep 2023 15:37:11 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v20]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <D-j-mI6DR40a0OnhchO3zvxFY3a-ky83YmRzpGPi2nI=.4157cb12-7635-47a3-8c1b-000fa21cd805@github.com>

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

 - 8315917: Passing struct by values seems under specified
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - Merge branch 'master' into JEP22
 - add code snippet
 - Split long throws clauses in `MemorySegment` javadoc
   
   Reviewed-by: jvernee
 - Add support for sliced allocation
 - add name of SysV ABI
 - Fix javadoc issues in MemorySegment::copy
   
   Reviewed-by: jvernee
 - remove reference to allocateArray
 - PPC linker changes
 - ... and 33 more: https://git.openjdk.org/jdk/compare/35bccacb...0e702f06

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=19
  Stats: 3759 lines in 244 files changed: 1901 ins; 1000 del; 858 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

From duke at openjdk.org  Mon Sep 11 21:18:49 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 11 Sep 2023 21:18:49 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v20]
In-Reply-To: <D-j-mI6DR40a0OnhchO3zvxFY3a-ky83YmRzpGPi2nI=.4157cb12-7635-47a3-8c1b-000fa21cd805@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <D-j-mI6DR40a0OnhchO3zvxFY3a-ky83YmRzpGPi2nI=.4157cb12-7635-47a3-8c1b-000fa21cd805@github.com>
Message-ID: <6ekIcAU0bARYkB_E_QCPD4u9jnqtFgEXCpImDcaxVPE=.a2b116fe-409b-4867-a389-d53ad1a94873@github.com>

On Mon, 11 Sep 2023 15:37:11 GMT, Jorn Vernee <jvernee at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 43 commits:
> 
>  - 8315917: Passing struct by values seems under specified
>    
>    Reviewed-by: mcimadamore
>  - Merge branch 'master' into JEP22
>  - Merge branch 'master' into JEP22
>  - add code snippet
>  - Split long throws clauses in `MemorySegment` javadoc
>    
>    Reviewed-by: jvernee
>  - Add support for sliced allocation
>  - add name of SysV ABI
>  - Fix javadoc issues in MemorySegment::copy
>    
>    Reviewed-by: jvernee
>  - remove reference to allocateArray
>  - PPC linker changes
>  - ... and 33 more: https://git.openjdk.org/jdk/compare/35bccacb...0e702f06

src/java.base/share/classes/java/lang/foreign/Linker.java line 573:

> 571:      * The returned method handle will throw an {@link IllegalArgumentException} if the {@link MemorySegment}
> 572:      * representing the target address of the foreign function is the {@link MemorySegment#NULL} address. If an argument
> 573:      * is a {@link MemorySegment},whose corresponding layout is an {@linkplain GroupLayout group layout}, the linker might attempt to access the contents of the segment. As such, one of the exceptions specified by the

**Nit:**
Suggestion:

     * is a {@link MemorySegment},whose corresponding layout is a {@linkplain GroupLayout group layout}, the linker might attempt to access the contents of the segment. As such, one of the exceptions specified by the

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1322081045

From naoto at openjdk.org  Mon Sep 11 22:28:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 11 Sep 2023 22:28:57 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
Message-ID: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>

Simple clean-up for removing an unnecessary condition.

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

Commit messages:
 - initial commit

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

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

From serb at openjdk.org  Mon Sep 11 23:45:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 11 Sep 2023 23:45:38 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <o-QFfr2q4YtYnj5Vri0-lmYHvPWdCyEKXBblcv3uh7w=.1db2eb23-e6a6-42a8-96f2-eaa283bdb138@github.com>

On Sat, 9 Sep 2023 14:33:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 52:

> 50:  * starting number is set to 0xFFFF or when we have a valid Zip64 Extra header
> 51:  * size but missing the corresponding field.
> 52:  * @run junit MissingZIP64EntriesTest

Is this comment accurate? I think we should check 3 cases when the header extra len == 0, len == 8 and len ==16, but still do not contain all required information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1322185302

From aturbanov at openjdk.org  Tue Sep 12 06:36:38 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Sep 2023 06:36:38 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <rnUimWAK3X0hncMCofl8Ipqx16u993s4-4h_XUyjTi8=.f516a656-8321-4968-8e49-3d7159cfaaae@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/15672#pullrequestreview-1621397162

From vtewari at openjdk.org  Tue Sep 12 06:59:38 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Tue, 12 Sep 2023 06:59:38 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <va_gPV1L776t-MS2QZqO-lOPq5MkPs9bMUJpybXPdzk=.2a8e8dd0-1f4a-4b54-a564-60472cd5d1a2@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

Looks OK to me.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15672#pullrequestreview-1621457607

From aturbanov at openjdk.org  Tue Sep 12 08:49:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Sep 2023 08:49:41 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <ZHM6HUjHlSHTyn-_OuBhOktlfO30zsCIBfUcZ7UrRWw=.c4a22d8f-87d6-4659-984e-fb632c55e408@github.com>

On Sat, 9 Sep 2023 14:33:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 198:

> 196:      * actual value is stored in the Zip64 Extra Header
> 197:      */
> 198:     private static final int  ZIP64_MAGICCOUNT = 0xFFFF;

Suggestion:

    private static final int ZIP64_MAGICCOUNT = 0xFFFF;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1322670868

From jvernee at openjdk.org  Tue Sep 12 10:49:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Sep 2023 10:49:38 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <u__LniO_3mS-93WVTcYqKz76HZsC96Qu3Ew9gYWeQ94=.2a787c3b-2d6c-42c1-97b4-b9e3c6ce2e06@github.com>

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

 - add missing space + reflow lines
 - Fix typo
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/0e702f06..e68b95c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=19-20

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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

From rriggs at openjdk.org  Tue Sep 12 13:34:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Sep 2023 13:34:40 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <ydS56V_d8TWJCAeSk7_2XV8enU-PYkuqDcsO6lIMJ1U=.82ef1ad9-79c6-4260-800c-af505f98fcb8@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15672#pullrequestreview-1622268369

From iris at openjdk.org  Tue Sep 12 16:51:40 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 12 Sep 2023 16:51:40 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <ryJQhpdt69AuS4J8GunAIfJz-imGIOgAOd15JWwU2yE=.8c37c02c-789a-4412-a60c-c746b9c0ee07@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15672#pullrequestreview-1622710270

From github at paul.kungfoocoder.org  Tue Sep 12 17:05:49 2023
From: github at paul.kungfoocoder.org (github at paul.kungfoocoder.org)
Date: Tue, 12 Sep 2023 19:05:49 +0200
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
Message-ID: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>

Recently we came across a very surprising situation.

In our code we were doing something similar to:

echo 'new java.io.ByteArrayInputStream(new byte[256*1024*1024]).transferTo(new java.io.FileOutputStream("/tmp/aaa"));' | jshell -R-XX:MaxDirectMemorySize=25M

Which works perfectly well. For various reasons some of the code was adapted to use Paths, instead of Files, and this was changed to (effectively):

echo 'java.nio.file.Files.copy(new java.io.ByteArrayInputStream(new byte[256*1024*1024]), java.nio.file.Path.of("/tmp/aaa"), java.nio.file.StandardCopyOption.REPLACE_EXISTING);' | jshell -R-XX:MaxDirectMemorySize=25M

Whereupon it started to fail with a message similar to:
Exception java.lang.OutOfMemoryError: Cannot reserve 268435456 bytes of direct buffer memory (allocated: 127, limit: 26214400)
Note that this isn't strictly a problem of Files.copy, but rather of the output stream returned byFiles.newOutputStream, as evidenced by echo 'new java.io.ByteArrayInputStream(new byte[256*1024*1024]).transferTo(java.nio.file.Files.newOutputStream(java.nio.file.Path.of("/tmp/aaa")));' | jshell -R-XX:MaxDirectMemorySize=25M 

This makes it much harder to use a Path, since we cannot know whether or not it will be possible to write to the file or not.

This fails on all of Java 11 (11.0.18), Java 17 (17.0.8), and Java 20 (openjdk 20.0.2 2023-07-18), and has been tested on both Mac and Linux.

In this particular code path, the easiest fix is to replace https://github.com/adoptium/jdk/blob/d0be73a78038faf9509623bc4ba71eb4385cd645/src/java.base/share/classes/sun/nio/ch/IOUtil.java#L94 with something like:

            bb = Util.getTemporaryDirectBuffer(Math.min(rem, VM.maxDirectMemory()/2));
Since the code outside of this method already loops until the ByteBuffer is full, at least on this code path. Other code paths should also retry, since Channel.write() doesn't guarantee to write all bytes anyway. A better fix would be to look at how much memory is available, and allocate that much, or to fall back to a streaming copy, similar to what the default InputStream.transferTo already does.

You might wonder _why_ we limit the MaxDirectMemorySize, and we do so since we found that if we don?t it can lead to the OOMKiller killing our containers, due to memory being allocated outside of the heap. Nonetheless, whether it should be limited or not, then I still find it very surprising that I can do inputStream.transferTo(fileOutputStream) and expect that it will work, regardless of the InputStream, but I cannot do the same with inputStream.transferTo(channelOutputStream), as that might fail depending on how much data is available in the input stream, and the amount of available Direct Memory.

Discussion also raised with Adoptium, where they suggested to post it here.
https://github.com/adoptium/adoptium-support/issues/894?

For our product, I have changed Files.copy() everywhere to use InputStream.transferTo(fileOutputStream), but this doesn?t seem like it is the intended result. I look forward to your responses on how we can best deal with this within Java.

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230912/a4764a66/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apple-touch-icon-180x180.png
Type: image/png
Size: 21128 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230912/a4764a66/apple-touch-icon-180x180-0001.png>

From naoto at openjdk.org  Tue Sep 12 18:18:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Sep 2023 18:18:39 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <YuIbw2jUgs_MMycDLQzVCd-2NlQ_RCwnGw6fsl2dLhQ=.e4b3b594-dc72-4377-8dbc-5b2ea3172b59@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15672#issuecomment-1716206239

From naoto at openjdk.org  Tue Sep 12 18:21:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 12 Sep 2023 18:21:44 GMT
Subject: Integrated: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <mjH1yUT_B8yumKJYfkTHbNruu52WcCnxVMlZ73GPt-4=.529f335f-15fc-41ae-9f5c-47a116f25957@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

This pull request has now been integrated.

Changeset: ac2dfe45
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac2dfe45d1b7fb9b99b0ba1402189de1791319b8
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8313865: Always true condition in sun.nio.cs.CharsetMapping#readINDEXC2B

Reviewed-by: aturbanov, vtewari, rriggs, iris

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

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

From Alan.Bateman at oracle.com  Tue Sep 12 18:58:24 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 12 Sep 2023 19:58:24 +0100
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
In-Reply-To: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
References: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
Message-ID: <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>



On 12/09/2023 18:05, github at paul.kungfoocoder.org wrote:
> Recently we came across a very surprising situation.
>
> In our code we were doing something similar to:
>
>     echo 'new java.io.ByteArrayInputStream(new
>     byte[256*1024*1024]).transferTo(new
>     java.io.FileOutputStream("/tmp/aaa"));' | jshell
>     -R-XX:MaxDirectMemorySize=25M
>
>
> Which works perfectly well. For various reasons some of the code was 
> adapted to use Paths, instead of Files, and this was changed to 
> (effectively):
>
>
>     echo 'java.nio.file.Files.copy(new
>     java.io.ByteArrayInputStream(new byte[256*1024*1024]),
>     java.nio.file.Path.of("/tmp/aaa"),
>     java.nio.file.StandardCopyOption.REPLACE_EXISTING);' | jshell
>     -R-XX:MaxDirectMemorySize=25M
>
>
> Whereupon it started to fail with a message similar to:
> |Exception java.lang.OutOfMemoryError: Cannot reserve 268435456 bytes 
> of direct buffer memory (allocated: 127, limit: 26214400)|
> Note that this isn't strictly a problem of |Files.copy|, but rather of 
> the output stream returned by|Files.newOutputStream|, as evidenced by 
> |echo 'new java.io.ByteArrayInputStream(new 
> byte[256*1024*1024]).transferTo(java.nio.file.Files.newOutputStream(java.nio.file.Path.of("/tmp/aaa")));' 
> | jshell -R-XX:MaxDirectMemorySize=25M|
>
Right, it's ChannelOutputStream.writeFully that doesn't limit the size 
of the writes to the underlying FileChannel. Improving that would reduce 
direct buffer usage for several operations (not just copy).

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230912/d1a5d3d2/attachment-0001.htm>

From erikj at openjdk.org  Tue Sep 12 20:18:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:51 GMT
Subject: RFR: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <voTsZOBLJzcqq6sseL9fyaUN7-hcImBW9tyGILGGqSc=.d0734a02-5078-446c-b4b5-35e84fa7aedd@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Thanks for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1716362585

From erikj at openjdk.org  Tue Sep 12 20:18:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:52 GMT
Subject: Integrated: 8267174: Many test files have the wrong Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <0l5wbPPACAFDpuzCNnCNkr_RJ35CFXxPC9EpiVFt_Ao=.fbfbc877-43fd-4706-9d0d-bace4d004632@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

This pull request has now been integrated.

Changeset: 020255a7
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/020255a72dc374ba0bdd44772047f14a8bfe69a9
Stats:     1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod

8267174: Many test files have the wrong Copyright header

Reviewed-by: valeriep, aivanov, iris, dholmes, ihse

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

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

From github at paul.kungfoocoder.org  Tue Sep 12 21:39:20 2023
From: github at paul.kungfoocoder.org (github at paul.kungfoocoder.org)
Date: Tue, 12 Sep 2023 23:39:20 +0200
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
In-Reply-To: <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>
References: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
 <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>
Message-ID: <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>

Hi Alan,

> On 12 Sep 2023, at 20:58, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 12/09/2023 18:05, github at paul.kungfoocoder.org <mailto:github at paul.kungfoocoder.org> wrote:
>> Note that this isn't strictly a problem of Files.copy, but rather of the output stream returned byFiles.newOutputStream, as evidenced by echo 'new java.io.ByteArrayInputStream(new byte[256*1024*1024]).transferTo(java.nio.file.Files.newOutputStream(java.nio.file.Path.of("/tmp/aaa")));' | jshell -R-XX:MaxDirectMemorySize=25M 
>> 
> Right, it's ChannelOutputStream.writeFully that doesn't limit the size of the writes to the underlying FileChannel. Improving that would reduce direct buffer usage for several operations (not just copy).

Agreed. My question is what is the next step now that I have identified this problem? Do others agree that this is something that should be fixed? What can I do to move this forward?

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230912/bca00321/attachment.htm>

From brian.burkhalter at oracle.com  Tue Sep 12 21:45:25 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 12 Sep 2023 21:45:25 +0000
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
In-Reply-To: <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
References: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
 <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>
 <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
Message-ID: <89C62F02-4445-426D-985F-D1F758C32671@oracle.com>


On Sep 12, 2023, at 2:39 PM, github at paul.kungfoocoder.org<mailto:github at paul.kungfoocoder.org> wrote:

Agreed. My question is what is the next step now that I have identified this problem? Do others agree that this is something that should be fixed? What can I do to move this forward?

One helpful thing would be to file an issue [1] so this stays on the radar.

Thanks,

Brian

[1] https://bugs.java.com/bugdatabase/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230912/2606d989/attachment-0001.htm>

From bpb at openjdk.org  Wed Sep 13 02:32:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Sep 2023 02:32:31 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>

> Check that the source is readable before deleting the destination.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8073061: Improve file access checking; modify a test; add a test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15501/files
  - new: https://git.openjdk.org/jdk/pull/15501/files/65009624..ec6c7ddd

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

  Stats: 293 lines in 3 files changed: 254 ins; 38 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15501/head:pull/15501

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

From shade at openjdk.org  Wed Sep 13 07:25:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Sep 2023 07:25:51 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
Message-ID: <8WblmPqvCEIhbxhHIjxraFWCc2rNga9T8pPCBLXvcIQ=.cdbe4a70-cac8-4563-8bff-69bc7cb0f5cb@github.com>

On Mon, 11 Sep 2023 22:21:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple clean-up for removing an unnecessary condition.

src/java.base/share/classes/sun/nio/cs/CharsetMapping.java line 242:

> 240:         char[] map = readCharArray();
> 241:         for (int i = map.length - 1; i >= 0; i--) {
> 242:             if (c2b == null) {

Post-review comment:

I don't quite understand this code. `c2b` is loop-invariant, right? So, what this does is checking for `c2b != null`, and if so, instantiates the `c2b` array with `new char[map[map.length - 1] + 256]`. This does not even require a loop, as written right now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15672#discussion_r1324084796

From Alan.Bateman at oracle.com  Wed Sep 13 07:41:31 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Sep 2023 08:41:31 +0100
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
In-Reply-To: <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
References: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
 <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>
 <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
Message-ID: <8640bb10-9b3a-bb67-862a-c625614e441a@oracle.com>

On 12/09/2023 22:39, github at paul.kungfoocoder.org wrote:
> Do others agree that this is something that should be fixed?

I've created JDK-8316156 [1] to look at this. The wrapping of the byte[] 
and writing the full size to the channel has always been there, but 
maybe not really noticed either due to usages or not limiting direct 
memory like you are doing.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8316156

From naoto at openjdk.org  Wed Sep 13 18:02:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 18:02:50 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <8WblmPqvCEIhbxhHIjxraFWCc2rNga9T8pPCBLXvcIQ=.cdbe4a70-cac8-4563-8bff-69bc7cb0f5cb@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
 <8WblmPqvCEIhbxhHIjxraFWCc2rNga9T8pPCBLXvcIQ=.cdbe4a70-cac8-4563-8bff-69bc7cb0f5cb@github.com>
Message-ID: <dciXo_HcqRtj6fLXnmXEcEp96BJtp_rfKGFCrJobQuk=.292dbb8a-c058-439a-8827-301f05b6d57b@github.com>

On Wed, 13 Sep 2023 07:22:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Simple clean-up for removing an unnecessary condition.
>
> src/java.base/share/classes/sun/nio/cs/CharsetMapping.java line 242:
> 
>> 240:         char[] map = readCharArray();
>> 241:         for (int i = map.length - 1; i >= 0; i--) {
>> 242:             if (c2b == null) {
> 
> Post-review comment:
> 
> I don't quite understand this code. `c2b` is loop-invariant, right? So, what this does is checking for `c2b != null`, and if so, instantiates the `c2b` array with `new char[map[map.length - 1] + 256]`. This does not even require a loop, as written right now.

Indeed the code looks weird. Will have a deeper look. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15672#discussion_r1324881959

From duke at openjdk.org  Wed Sep 13 19:48:46 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 13 Sep 2023 19:48:46 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
In-Reply-To: <u__LniO_3mS-93WVTcYqKz76HZsC96Qu3Ew9gYWeQ94=.2a787c3b-2d6c-42c1-97b4-b9e3c6ce2e06@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u__LniO_3mS-93WVTcYqKz76HZsC96Qu3Ew9gYWeQ94=.2a787c3b-2d6c-42c1-97b4-b9e3c6ce2e06@github.com>
Message-ID: <zWVa5Ac4J4t_2qg1I-8YEiGB-6hmAjAazCkfgK6xg-Q=.a26b791f-b79e-467b-b302-c287ff48c350@github.com>

On Tue, 12 Sep 2023 10:49:38 GMT, Jorn Vernee <jvernee at openjdk.org> 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:
> 
>  - add missing space + reflow lines
>  - Fix typo
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 311:

> 309:         };
> 310: 
> 311:         CANONICAL_LAYOUTS = Map.ofEntries(

`LibFallback::wcharSize()` and?other?getters for?`LibFallback.NativeConstants`?fields can?throw an?error when?`LibFallback.SUPPORTED` is?`false` due?to the?`fallbackLinker`?library not?being?present, so?this static?initializer should?be?made into?a?method?instead:
Suggestion:

    static final Map<String, MemoryLayout> CANONICAL_LAYOUTS = initCanonicalLayouts();

    private static Map<String, MemoryLayout> initCanonicalLayouts() {
        if (!isSupported()) {
            return null;
        }

        int wchar_size = LibFallback.wcharSize();
        MemoryLayout wchartLayout = switch(wchar_size) {
            case 2 -> JAVA_CHAR; // prefer JAVA_CHAR
            default -> FFIType.layoutFor(wchar_size);
        };

        return Map.ofEntries(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1324996396

From bpb at openjdk.org  Thu Sep 14 03:16:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 03:16:23 GMT
Subject: RFR: 8316156: (ch) Channels.newOutputStream(ch).write(bigByteArray)
 allocates a lot of direct memory
Message-ID: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>

In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

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

Commit messages:
 - 8316156: Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct memory

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

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

From duke at openjdk.org  Thu Sep 14 03:24:46 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Thu, 14 Sep 2023 03:24:46 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 49:

> 47:  */
> 48: class ChannelInputStream extends InputStream {
> 49:     static final int DEFAULT_BUFFER_SIZE = 8192;

Since this buffer size is now being used in more places, is it worth testing with 16KiB to match `InputStream` from https://github.com/openjdk/jdk/pull/11783?

Suggestion:

    static final int DEFAULT_BUFFER_SIZE = 16384;



https://github.com/openjdk/jdk/blob/11d431b2c436d6b2a0aa7a00d676a93c1b87da0e/src/java.base/share/classes/java/io/InputStream.java#L56

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325307780

From duke at openjdk.org  Thu Sep 14 04:24:37 2023
From: duke at openjdk.org (Bernd)
Date: Thu, 14 Sep 2023 04:24:37 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <NEraGqj-CDbt_eQ1c6XUe-dCZQNfnLiddjO8Yar2pho=.2084d5fd-c2f9-4e48-bcb6-f099913166bc@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 73:

> 71:         int rem = bb.limit() - pos;
> 72:         while (rem > 0) {
> 73:             int size = Integer.min(rem, DEFAULT_BUFFER_SIZE);

Should this limit in the read case not apply for direct buffers? (I.e. they are allocated already?). Also should it really use ?DeFAULT_? maybe more like a CHUnK_LIMIT more around 128k?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325336015

From alanb at openjdk.org  Thu Sep 14 06:33:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 06:33:38 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <Gb-mN01dDqpvGyso6F0YETOOO1XeEpoWxVh44TU6W8g=.59417896-5949-463c-8479-037852c786bf@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 49:

> 47:  */
> 48: class ChannelInputStream extends InputStream {
> 49:     static final int DEFAULT_BUFFER_SIZE = 8192;

I don't think COS should be using CIS.DEFAULT_BUFFER_SIZE, maybe it should be moved to Streams which is the factory class for the streams based on channels.

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 68:

> 66:      * If the channel is selectable then it must be configured blocking.
> 67:      */
> 68:     private int readFully(ByteBuffer bb) throws IOException {

InputStream.read methods are not "read fully", it will cause the read to hang, say where you read some bytes and block indefinitely to fill the user's buffer.

test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 54:

> 52:                 throw new RuntimeException("Arrays are not equal");
> 53:         } finally {
> 54:             Files.delete(target);

The test is for CIS.read/COS.write so I guess it should directly exercise those methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325421210
PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325422565
PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325422995

From alanb at openjdk.org  Thu Sep 14 06:48:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 06:48:35 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <NEraGqj-CDbt_eQ1c6XUe-dCZQNfnLiddjO8Yar2pho=.2084d5fd-c2f9-4e48-bcb6-f099913166bc@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <NEraGqj-CDbt_eQ1c6XUe-dCZQNfnLiddjO8Yar2pho=.2084d5fd-c2f9-4e48-bcb6-f099913166bc@github.com>
Message-ID: <PFxzc7hpV6-6GFlyLAgZsqxltAln4WJf41_rK-FM3lQ=.8da0445b-760e-4af0-be63-325d2d5d516a@github.com>

On Thu, 14 Sep 2023 04:22:03 GMT, Bernd <duke at openjdk.org> wrote:

> Should this limit in the read case not apply for direct buffers? (I.e. they are allocated already?). Also should it really use ?DeFAULT_? maybe more like a CHUnK_LIMIT more around 128k?

There is an argument that the channels (the implementations SocketChannel, FileChannel, ...) should clamp the size when called with a ByteBuffer that is backed by a byte[]. I think we have to be cautious about changing things at that level as it would have much wider impact. It also gets more complicated with scatter/gather ops.

So clamping in the input stream/output streams as done in the COS.write change is okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325427962

From sgehwolf at openjdk.org  Thu Sep 14 08:19:39 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Sep 2023 08:19:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <pM-RkXK9Klfm7IoIneZ1HTfEb4rRwOnv5VIYO95MbXI=.f0a10d77-bdbe-4d9d-b39a-76b6f9145b29@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 26:

> 24: /* @test
> 25:  * @bug 8316156
> 26:  * @summary Ensure Channels.newOutputStream.write doe not overrun max memory

Typo: `does not` over `doe not`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325561423

From vtewari at openjdk.org  Thu Sep 14 11:05:39 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 14 Sep 2023 11:05:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <FwqVRdolv_i9TGzWcWLaiSsJuIZhQk_VfYSPgtU29a0=.988a23ad-c7be-4878-bdb7-0f667d5ce49d@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 52:

> 50:             byte[] res = Files.readAllBytes(target);
> 51:             if (!Arrays.equals(b, res))
> 52:                 throw new RuntimeException("Arrays are not equal");

Will this 'throw new RuntimeException("Arrays are not equal");' be ever thrown ?.

I tested without fix and 'java.lang.OutOfMemoryError' wiil be thrown at line 49(Files.copy) so even in failing case 'RuntimeException' will not be thrown.

By looking the test name 'WriteFullyMemorySize'  it is not clear to me what it is trying to test. If  you wants to test 'Files.readAllBytes' as well then i will suggest you to  change the name of test or put some comment. It will help the future maintainer of the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1325781083

From lancea at openjdk.org  Thu Sep 14 15:57:43 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:43 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <hYMCyltFznUXD-b5kJ7PFhrmowbZQPsYVxEdB11HnmE=.0d0e3c22-3512-4256-9179-c5b5766250e3@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added additional tests, along with additional cleanup and refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/bb962fcf..40504b2c

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

  Stats: 737 lines in 3 files changed: 578 ins; 99 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From bpb at openjdk.org  Thu Sep 14 15:57:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 15:57:37 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <fGZ3D91szUiScbGTKHz_CqmOoc3AHpdK9AlYN-Yi1Aw=.8507c1d7-7ba6-42c3-a225-5ee3756cd805@github.com>

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316156: Address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15733/files
  - new: https://git.openjdk.org/jdk/pull/15733/files/0e6d206f..a9af89cf

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

  Stats: 143 lines in 5 files changed: 75 ins; 59 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15733/head:pull/15733

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

From lancea at openjdk.org  Thu Sep 14 15:57:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:45 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
In-Reply-To: <o-QFfr2q4YtYnj5Vri0-lmYHvPWdCyEKXBblcv3uh7w=.1db2eb23-e6a6-42a8-96f2-eaa283bdb138@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
 <o-QFfr2q4YtYnj5Vri0-lmYHvPWdCyEKXBblcv3uh7w=.1db2eb23-e6a6-42a8-96f2-eaa283bdb138@github.com>
Message-ID: <qHqS7qODfZZz7ELLYFi3ofVSApGcjoAKa2ngo5S4nFA=.e7966655-768d-488a-94ca-af8131eec86b@github.com>

On Mon, 11 Sep 2023 23:42:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added additional tests, along with additional cleanup and refactoring
>
> test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 52:
> 
>> 50:  * starting number is set to 0xFFFF or when we have a valid Zip64 Extra header
>> 51:  * size but missing the corresponding field.
>> 52:  * @run junit MissingZIP64EntriesTest
> 
> Is this comment accurate? I think we should check 3 cases when the header extra len == 0, len == 8 and len ==16, but still do not contain all required information.

Clarified the comment to make it a bit clearer and also added additional tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1326168515

From bpb at openjdk.org  Thu Sep 14 15:57:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 15:57:41 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <Gb-mN01dDqpvGyso6F0YETOOO1XeEpoWxVh44TU6W8g=.59417896-5949-463c-8479-037852c786bf@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <Gb-mN01dDqpvGyso6F0YETOOO1XeEpoWxVh44TU6W8g=.59417896-5949-463c-8479-037852c786bf@github.com>
Message-ID: <-lcjY53JlsFeSU_uUF_9_7idqDofnuVGOZEh83jsO4U=.f038bfc4-28e6-490d-a0cb-f1495026aa8e@github.com>

On Thu, 14 Sep 2023 06:28:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Address reviewer comments
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 49:
> 
>> 47:  */
>> 48: class ChannelInputStream extends InputStream {
>> 49:     static final int DEFAULT_BUFFER_SIZE = 8192;
> 
> I don't think COS should be using CIS.DEFAULT_BUFFER_SIZE, maybe it should be moved to Streams which is the factory class for the streams based on channels.

Moved to `Streams` in a9af89cff869c441c6dd04f635a4d93e7757f2fa.

> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 68:
> 
>> 66:      * If the channel is selectable then it must be configured blocking.
>> 67:      */
>> 68:     private int readFully(ByteBuffer bb) throws IOException {
> 
> InputStream.read methods are not "read fully", it will cause the read to hang, say where you read some bytes and block indefinitely to fill the user's buffer.

I was ambivalent about that name as well. Changed in a9af89cff869c441c6dd04f635a4d93e7757f2fa.

> test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 54:
> 
>> 52:                 throw new RuntimeException("Arrays are not equal");
>> 53:         } finally {
>> 54:             Files.delete(target);
> 
> The test is for CIS.read/COS.write so I guess it should directly exercise those methods.

So changed in a9af89cff869c441c6dd04f635a4d93e7757f2fa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326165608
PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326166354
PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326167019

From lancea at openjdk.org  Thu Sep 14 15:57:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 15:57:48 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v2]
In-Reply-To: <ZHM6HUjHlSHTyn-_OuBhOktlfO30zsCIBfUcZ7UrRWw=.c4a22d8f-87d6-4659-984e-fb632c55e408@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
 <ZHM6HUjHlSHTyn-_OuBhOktlfO30zsCIBfUcZ7UrRWw=.c4a22d8f-87d6-4659-984e-fb632c55e408@github.com>
Message-ID: <Z8iBLqFnniiTlryYzhbu9vG8V5xdECb90w8o7elkmyw=.9d16d9de-64e0-4a06-99d4-218abe722dfb@github.com>

On Tue, 12 Sep 2023 08:47:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added additional tests, along with additional cleanup and refactoring
>
> test/jdk/java/util/zip/ZipFile/MissingZIP64EntriesTest.java line 198:
> 
>> 196:      * actual value is stored in the Zip64 Extra Header
>> 197:      */
>> 198:     private static final int  ZIP64_MAGICCOUNT = 0xFFFF;
> 
> Suggestion:
> 
>     private static final int ZIP64_MAGICCOUNT = 0xFFFF;

Removed the extra space.  thank you for pointing it out

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15650#discussion_r1326169219

From bpb at openjdk.org  Thu Sep 14 15:57:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 15:57:43 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>
Message-ID: <dRec0_7eODvQDZ4CmdbSUd2Ch3lvM5od7Meox7nPrmM=.26ed0d8f-572d-4cc4-8fdc-6104b8bd7747@github.com>

On Thu, 14 Sep 2023 03:20:00 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Address reviewer comments
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 49:
> 
>> 47:  */
>> 48: class ChannelInputStream extends InputStream {
>> 49:     static final int DEFAULT_BUFFER_SIZE = 8192;
> 
> Since this buffer size is now being used in more places, is it worth testing with 16KiB to match `InputStream` from https://github.com/openjdk/jdk/pull/11783?
> 
> Suggestion:
> 
>     static final int DEFAULT_BUFFER_SIZE = 16384;
> 
> 
> 
> https://github.com/openjdk/jdk/blob/11d431b2c436d6b2a0aa7a00d676a93c1b87da0e/src/java.base/share/classes/java/io/InputStream.java#L56

I can look into running a benchmark on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326169936

From bpb at openjdk.org  Thu Sep 14 15:57:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 15:57:46 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <pM-RkXK9Klfm7IoIneZ1HTfEb4rRwOnv5VIYO95MbXI=.f0a10d77-bdbe-4d9d-b39a-76b6f9145b29@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <pM-RkXK9Klfm7IoIneZ1HTfEb4rRwOnv5VIYO95MbXI=.f0a10d77-bdbe-4d9d-b39a-76b6f9145b29@github.com>
Message-ID: <YFEfuXRDAtgTLCmjrPZvcBOqYbmALRSSCo1ApusDZzY=.c5472405-b652-45e6-a40d-4c82a0228e39@github.com>

On Thu, 14 Sep 2023 08:17:03 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Address reviewer comments
>
> test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 26:
> 
>> 24: /* @test
>> 25:  * @bug 8316156
>> 26:  * @summary Ensure Channels.newOutputStream.write doe not overrun max memory
> 
> Typo: `does not` over `doe not`

Thanks. Typo fixed in a9af89cff869c441c6dd04f635a4d93e7757f2fa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326167586

From bpb at openjdk.org  Thu Sep 14 15:57:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 15:57:49 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <FwqVRdolv_i9TGzWcWLaiSsJuIZhQk_VfYSPgtU29a0=.988a23ad-c7be-4878-bdb7-0f667d5ce49d@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <FwqVRdolv_i9TGzWcWLaiSsJuIZhQk_VfYSPgtU29a0=.988a23ad-c7be-4878-bdb7-0f667d5ce49d@github.com>
Message-ID: <bYlZmg1cmlYc_qVUEhBfPyCHJe0z2d-v8CfpvEhBfwk=.e7b5d6d4-7b86-47b1-9575-87d7d73170b9@github.com>

On Thu, 14 Sep 2023 11:02:42 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Address reviewer comments
>
> test/jdk/java/nio/channels/Channels/WriteFullyMemorySize.java line 52:
> 
>> 50:             byte[] res = Files.readAllBytes(target);
>> 51:             if (!Arrays.equals(b, res))
>> 52:                 throw new RuntimeException("Arrays are not equal");
> 
> Will this 'throw new RuntimeException("Arrays are not equal");' be ever thrown ?.
> 
> I tested without fix and 'java.lang.OutOfMemoryError' wiil be thrown at line 49(Files.copy) so even in failing case 'RuntimeException' will not be thrown.
> 
> By looking the test name 'WriteFullyMemorySize'  it is not clear to me what it is trying to test. If  you wants to test 'Files.readAllBytes' as well then i will suggest you to  change the name of test or put some comment. It will help the future maintainer of the code.

The `Arrays.equals` is anticipatory. The test is changed in a9af89cff869c441c6dd04f635a4d93e7757f2fa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326168451

From lancea at openjdk.org  Thu Sep 14 16:09:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Sep 2023 16:09:20 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v3]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <LSxwcnKWzRg-ud5xP1OvEiSTihEcCQakSrVlT0rQl-k=.31c02805-00ff-4534-b070-cbdf56c52edc@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Remove tab(s) from comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/40504b2c..24b159d8

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

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

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

From bpb at openjdk.org  Thu Sep 14 16:22:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 16:22:42 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <fGZ3D91szUiScbGTKHz_CqmOoc3AHpdK9AlYN-Yi1Aw=.8507c1d7-7ba6-42c3-a225-5ee3756cd805@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <fGZ3D91szUiScbGTKHz_CqmOoc3AHpdK9AlYN-Yi1Aw=.8507c1d7-7ba6-42c3-a225-5ee3756cd805@github.com>
Message-ID: <Mw21fW244zY5rXGTp3jv45TCqLDlhWjg1X3qDekxeck=.dd30b706-b326-4794-a3eb-856eec5d15e3@github.com>

On Thu, 14 Sep 2023 15:57:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Address reviewer comments

Perhaps the test should be refactored to test `read` and `write` separately?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1719761549

From vtewari at openjdk.org  Thu Sep 14 17:13:40 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 14 Sep 2023 17:13:40 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v2]
In-Reply-To: <Mw21fW244zY5rXGTp3jv45TCqLDlhWjg1X3qDekxeck=.dd30b706-b326-4794-a3eb-856eec5d15e3@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <fGZ3D91szUiScbGTKHz_CqmOoc3AHpdK9AlYN-Yi1Aw=.8507c1d7-7ba6-42c3-a225-5ee3756cd805@github.com>
 <Mw21fW244zY5rXGTp3jv45TCqLDlhWjg1X3qDekxeck=.dd30b706-b326-4794-a3eb-856eec5d15e3@github.com>
Message-ID: <UXceEcL2PKa0NEndlLpdwtKQwB8bBU4VsZDF3Ag7wZ0=.d2afdaae-ee85-44fb-8448-1460ad142b58@github.com>

On Thu, 14 Sep 2023 16:19:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Perhaps the test should be refactored to test `read` and `write` separately?

that's good idea, separating read and write will make individual test's more readable/ maintainable.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1719839863

From bpb at openjdk.org  Thu Sep 14 19:25:35 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 19:25:35 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v3]
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <Taa0qAcBh-a--VSop88_y2cl-aTQYCRB_vD9EG706W0=.daaa9bcf-4624-44e3-bdbe-9554da6dbd9d@github.com>

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316156: Convert test to JUnit 5 and separate read/write testing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15733/files
  - new: https://git.openjdk.org/jdk/pull/15733/files/a9af89cf..c336780d

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

  Stats: 59 lines in 1 file changed: 36 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15733/head:pull/15733

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

From bpb at openjdk.org  Thu Sep 14 19:35:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 19:35:41 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v3]
In-Reply-To: <dRec0_7eODvQDZ4CmdbSUd2Ch3lvM5od7Meox7nPrmM=.26ed0d8f-572d-4cc4-8fdc-6104b8bd7747@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>
 <dRec0_7eODvQDZ4CmdbSUd2Ch3lvM5od7Meox7nPrmM=.26ed0d8f-572d-4cc4-8fdc-6104b8bd7747@github.com>
Message-ID: <I7YSW4CzPAgzpjTo7Unli6X7I-tZrxazwrWfph2vYeA=.3ea83e4c-1424-43fb-8ce5-ce0711b9632e@github.com>

On Thu, 14 Sep 2023 15:51:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 49:
>> 
>>> 47:  */
>>> 48: class ChannelInputStream extends InputStream {
>>> 49:     static final int DEFAULT_BUFFER_SIZE = 8192;
>> 
>> Since this buffer size is now being used in more places, is it worth testing with 16KiB to match `InputStream` from https://github.com/openjdk/jdk/pull/11783?
>> 
>> Suggestion:
>> 
>>     static final int DEFAULT_BUFFER_SIZE = 16384;
>> 
>> 
>> 
>> https://github.com/openjdk/jdk/blob/11d431b2c436d6b2a0aa7a00d676a93c1b87da0e/src/java.base/share/classes/java/io/InputStream.java#L56
>
> I can look into running a benchmark on this.

A quick measurement suggests that doubling the buffer size to 16384 would increase `read` throughput by more than 15%, and `write` throughput by more than 40%.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326429932

From alanb at openjdk.org  Thu Sep 14 19:35:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 19:35:46 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v3]
In-Reply-To: <Taa0qAcBh-a--VSop88_y2cl-aTQYCRB_vD9EG706W0=.daaa9bcf-4624-44e3-bdbe-9554da6dbd9d@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <Taa0qAcBh-a--VSop88_y2cl-aTQYCRB_vD9EG706W0=.daaa9bcf-4624-44e3-bdbe-9554da6dbd9d@github.com>
Message-ID: <C19WRLvgEwpeN-Fh70kt7hbgJ8FQUj4L3ijANjJz5QA=.e0743083-1fc0-4678-b231-5ee85a8623c7@github.com>

On Thu, 14 Sep 2023 19:25:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Convert test to JUnit 5 and separate read/write testing

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 84:

> 82:             rem -=n;
> 83:         }
> 84:         return nread;

This still looks like a "read fully", I don't think we should have a loop here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326429863

From bpb at openjdk.org  Thu Sep 14 19:38:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 19:38:42 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v3]
In-Reply-To: <C19WRLvgEwpeN-Fh70kt7hbgJ8FQUj4L3ijANjJz5QA=.e0743083-1fc0-4678-b231-5ee85a8623c7@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <Taa0qAcBh-a--VSop88_y2cl-aTQYCRB_vD9EG706W0=.daaa9bcf-4624-44e3-bdbe-9554da6dbd9d@github.com>
 <C19WRLvgEwpeN-Fh70kt7hbgJ8FQUj4L3ijANjJz5QA=.e0743083-1fc0-4678-b231-5ee85a8623c7@github.com>
Message-ID: <TDdvr5kQeGsNB51rVm5A_63zWTAz4bpCh4RGr8AEYCs=.1287b882-a44f-4f30-bf25-d9d9a2bad8f1@github.com>

On Thu, 14 Sep 2023 19:32:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Convert test to JUnit 5 and separate read/write testing
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 84:
> 
>> 82:             rem -=n;
>> 83:         }
>> 84:         return nread;
> 
> This still looks like a "read fully", I don't think we should have a loop here.

So only `Streams.DEFAULT_BUFFER_SIZE` bytes are read per call?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326433116

From alanb at openjdk.org  Thu Sep 14 20:12:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Sep 2023 20:12:40 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v3]
In-Reply-To: <TDdvr5kQeGsNB51rVm5A_63zWTAz4bpCh4RGr8AEYCs=.1287b882-a44f-4f30-bf25-d9d9a2bad8f1@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <Taa0qAcBh-a--VSop88_y2cl-aTQYCRB_vD9EG706W0=.daaa9bcf-4624-44e3-bdbe-9554da6dbd9d@github.com>
 <C19WRLvgEwpeN-Fh70kt7hbgJ8FQUj4L3ijANjJz5QA=.e0743083-1fc0-4678-b231-5ee85a8623c7@github.com>
 <TDdvr5kQeGsNB51rVm5A_63zWTAz4bpCh4RGr8AEYCs=.1287b882-a44f-4f30-bf25-d9d9a2bad8f1@github.com>
Message-ID: <_Ly0xG0kk3X2rOxdLel3tY2dDG7qy4qpLD7I_XpzTkA=.2af57402-3fbd-40c3-ab7d-96ac8e596031@github.com>

On Thu, 14 Sep 2023 19:35:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 84:
>> 
>>> 82:             rem -=n;
>>> 83:         }
>>> 84:         return nread;
>> 
>> This still looks like a "read fully", I don't think we should have a loop here.
>
> So at most `Streams.DEFAULT_BUFFER_SIZE` bytes would be read per call?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326463728

From siddhsql at gmail.com  Thu Sep 14 21:18:25 2023
From: siddhsql at gmail.com (Siddharth Jain)
Date: Thu, 14 Sep 2023 14:18:25 -0700
Subject: OverlappingFileLockException when trying to lock a filechannel twice
 in shared mode
Message-ID: <CAPqV3pRYsZhYFZxT5QQq3PsY0bAV8SfpKGPVRxa2zXtJfK71uA@mail.gmail.com>

Hello,

Using JDK-20, I have this code:

@Test
public void testRR() throws Exception {
var x1 = openForReading(file);
try {
var x2 = openForReading(file);
close(x2);
} finally {
close(x1);
}
}

private RafChannelPair openForReading(String filename) throws
FileNotFoundException, IOException {
RandomAccessFile raf = new RandomAccessFile(filename, "r");
FileChannel channel = raf.getChannel();
var lock = channel.tryLock(0, Long.MAX_VALUE, true);
if (lock != null && !lock.isShared()) {
System.out.println("Unable to acquire shared lock");
}
return new RafChannelPair(raf, channel, lock);
}

private void close(RafChannelPair x) throws IOException {
if (x.lock != null) {
x.lock.release();
}
x.channel.close();
x.raf.close();
}

I expect the code to throw no exception but when I run it I get:

[ERROR] testRR(com.mycompany.app.FileLockingTest)  Time elapsed: 0.007 s
 <<< ERROR!
java.nio.channels.OverlappingFileLockException
at com.mycompany.app.FileLockingTest.openForReading(FileLockingTest.java:69)
at com.mycompany.app.FileLockingTest.testRR(FileLockingTest.java:52)

is this not a bug? can someone explain it to me? if this is as expected
then what difference does it make whether one gives true or false to the
shared parameter of public abstract FileLock
<https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/nio/channels/FileLock.html>
 tryLock(long position,

               long size,
               boolean shared)

Thanks,

M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230914/4dd6af13/attachment.htm>

From siddhsql at gmail.com  Thu Sep 14 21:21:42 2023
From: siddhsql at gmail.com (Siddharth Jain)
Date: Thu, 14 Sep 2023 14:21:42 -0700
Subject: OverlappingFileLockException when trying to lock a filechannel
 twice in shared mode
In-Reply-To: <CAPqV3pRYsZhYFZxT5QQq3PsY0bAV8SfpKGPVRxa2zXtJfK71uA@mail.gmail.com>
References: <CAPqV3pRYsZhYFZxT5QQq3PsY0bAV8SfpKGPVRxa2zXtJfK71uA@mail.gmail.com>
Message-ID: <CAPqV3pS+XsJ1Cti=UrV77Gr6p_7ct2gdVX0NM8XQvBNYTmuQ8A@mail.gmail.com>

https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/nio/channels/FileLock.html
A file lock is either *exclusive* or *shared*. A shared lock prevents other
concurrently-running programs from acquiring an overlapping exclusive
lock, *but
does allow them to acquire overlapping shared locks.*

i am running this code on macos aarch64

On Thu, Sep 14, 2023 at 2:18?PM Siddharth Jain <siddhsql at gmail.com> wrote:

> Hello,
>
> Using JDK-20, I have this code:
>
> @Test
> public void testRR() throws Exception {
> var x1 = openForReading(file);
> try {
> var x2 = openForReading(file);
> close(x2);
> } finally {
> close(x1);
> }
> }
>
> private RafChannelPair openForReading(String filename) throws
> FileNotFoundException, IOException {
> RandomAccessFile raf = new RandomAccessFile(filename, "r");
> FileChannel channel = raf.getChannel();
> var lock = channel.tryLock(0, Long.MAX_VALUE, true);
> if (lock != null && !lock.isShared()) {
> System.out.println("Unable to acquire shared lock");
> }
> return new RafChannelPair(raf, channel, lock);
> }
>
> private void close(RafChannelPair x) throws IOException {
> if (x.lock != null) {
> x.lock.release();
> }
> x.channel.close();
> x.raf.close();
> }
>
> I expect the code to throw no exception but when I run it I get:
>
> [ERROR] testRR(com.mycompany.app.FileLockingTest)  Time elapsed: 0.007 s
>  <<< ERROR!
> java.nio.channels.OverlappingFileLockException
> at
> com.mycompany.app.FileLockingTest.openForReading(FileLockingTest.java:69)
> at com.mycompany.app.FileLockingTest.testRR(FileLockingTest.java:52)
>
> is this not a bug? can someone explain it to me? if this is as expected
> then what difference does it make whether one gives true or false to the
> shared parameter of public abstract FileLock
> <https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/nio/channels/FileLock.html>
>  tryLock(long position,
>
>                long size,
>                boolean shared)
>
> Thanks,
>
> M.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230914/2116c219/attachment-0001.htm>

From brian.burkhalter at oracle.com  Thu Sep 14 22:28:03 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 14 Sep 2023 22:28:03 +0000
Subject: OverlappingFileLockException when trying to lock a filechannel
 twice in shared mode
In-Reply-To: <CAPqV3pS+XsJ1Cti=UrV77Gr6p_7ct2gdVX0NM8XQvBNYTmuQ8A@mail.gmail.com>
References: <CAPqV3pRYsZhYFZxT5QQq3PsY0bAV8SfpKGPVRxa2zXtJfK71uA@mail.gmail.com>
 <CAPqV3pS+XsJ1Cti=UrV77Gr6p_7ct2gdVX0NM8XQvBNYTmuQ8A@mail.gmail.com>
Message-ID: <ACC6AA39-EA28-4892-89CD-46B84871B754@oracle.com>

A "concurrently running program? means a separate process. You are attempting to acquire two overlapping locks in the same process.

Brian

On Sep 14, 2023, at 2:21 PM, Siddharth Jain <siddhsql at gmail.com<mailto:siddhsql at gmail.com>> wrote:

https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/nio/channels/FileLock.html
A file lock is either exclusive or shared. A shared lock prevents other concurrently-running programs from acquiring an overlapping exclusive lock, but does allow them to acquire overlapping shared locks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230914/bf17f62a/attachment.htm>

From bpb at openjdk.org  Thu Sep 14 22:51:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Sep 2023 22:51:10 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316156: Read at most DEFAULT_BUFFER_SIZE bytes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15733/files
  - new: https://git.openjdk.org/jdk/pull/15733/files/c336780d..894d83ac

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

  Stats: 24 lines in 2 files changed: 3 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15733/head:pull/15733

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

From naoto at openjdk.org  Thu Sep 14 22:58:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Sep 2023 22:58:50 GMT
Subject: RFR: 8313865: Always true condition in
 sun.nio.cs.CharsetMapping#readINDEXC2B
In-Reply-To: <dciXo_HcqRtj6fLXnmXEcEp96BJtp_rfKGFCrJobQuk=.292dbb8a-c058-439a-8827-301f05b6d57b@github.com>
References: <xUA-2AOwTYjCVPntcNpZSgOYew70QVKscsNod3YIr94=.440c3d69-c85b-491e-bb82-af9c51933261@github.com>
 <8WblmPqvCEIhbxhHIjxraFWCc2rNga9T8pPCBLXvcIQ=.cdbe4a70-cac8-4563-8bff-69bc7cb0f5cb@github.com>
 <dciXo_HcqRtj6fLXnmXEcEp96BJtp_rfKGFCrJobQuk=.292dbb8a-c058-439a-8827-301f05b6d57b@github.com>
Message-ID: <hbToNe7IscklYf5Lz0JrReWhMxGGvlgn4db-hGl9IJA=.a032b016-4502-4d2a-8ca7-b9b9274fda77@github.com>

On Wed, 13 Sep 2023 18:00:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/cs/CharsetMapping.java line 242:
>> 
>>> 240:         char[] map = readCharArray();
>>> 241:         for (int i = map.length - 1; i >= 0; i--) {
>>> 242:             if (c2b == null) {
>> 
>> Post-review comment:
>> 
>> I don't quite understand this code. `c2b` is loop-invariant, right? So, what this does is checking for `c2b != null`, and if so, instantiates the `c2b` array with `new char[map[map.length - 1] + 256]`. This does not even require a loop, as written right now.
>
> Indeed the code looks weird. Will have a deeper look. Thanks!

The code seems to read the data written with this piece of code:
https://github.com/openjdk/jdk/blob/b55e418a077791b39992042411cde97f68dc39fe/make/jdk/src/classes/build/tools/charsetmapping/JIS0213.java#L145
but apparently it does not seem to work as expected. Since this is a very old code, not sure I would proactively modify it though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15672#discussion_r1326594363

From duke at openjdk.org  Thu Sep 14 23:37:39 2023
From: duke at openjdk.org (Bernd)
Date: Thu, 14 Sep 2023 23:37:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <PFxzc7hpV6-6GFlyLAgZsqxltAln4WJf41_rK-FM3lQ=.8da0445b-760e-4af0-be63-325d2d5d516a@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <NEraGqj-CDbt_eQ1c6XUe-dCZQNfnLiddjO8Yar2pho=.2084d5fd-c2f9-4e48-bcb6-f099913166bc@github.com>
 <PFxzc7hpV6-6GFlyLAgZsqxltAln4WJf41_rK-FM3lQ=.8da0445b-760e-4af0-be63-325d2d5d516a@github.com>
Message-ID: <JSANKbejzbBRM2WiJODogG3ML9OqDDSXHaKZKpATZoc=.d2d28a59-e7c7-4fb2-b732-699426112f67@github.com>

On Thu, 14 Sep 2023 06:35:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 73:
>> 
>>> 71:         int rem = bb.limit() - pos;
>>> 72:         while (rem > 0) {
>>> 73:             int size = Integer.min(rem, DEFAULT_BUFFER_SIZE);
>> 
>> Should this limit in the read case not apply for direct buffers? (I.e. they are allocated already?). Also should it really use ?DeFAULT_? maybe more like a CHUnK_LIMIT more around 128k?
>
>> Should this limit in the read case not apply for direct buffers? (I.e. they are allocated already?). Also should it really use ?DeFAULT_? maybe more like a CHUnK_LIMIT more around 128k?
> 
> There is an argument that the channels (the implementations SocketChannel, FileChannel, ...) should clamp the size when called with a ByteBuffer that is backed by a byte[]. I think we have to be cautious about changing things at that level as it would have much wider impact. It also gets more complicated with scatter/gather ops.
> 
> So clamping in the input stream/output streams as done in the COS.write change is okay.

Yes capping makes sense, but not at 8k level. If my app happens to know it can write to a raid5 system with 128k segment size (just to mention one particular example) and it already has allocated a direct buffer for this, it?s really wasteful to copy it in 8k chunks with heap buffers (especially as it would also trigger partial writes or rewrites on os level). That?s why I think the cap should be larger for some cases - that could depend on the target (file handle typically can be large blocks and network handles could depend on window size). I think synthetic benchmarks don?t cover that very well (at least that?s what I see when you talk about 8 or 16k chunks)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326616686

From duke at openjdk.org  Fri Sep 15 00:20:39 2023
From: duke at openjdk.org (David Schlosnagle)
Date: Fri, 15 Sep 2023 00:20:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <I7YSW4CzPAgzpjTo7Unli6X7I-tZrxazwrWfph2vYeA=.3ea83e4c-1424-43fb-8ce5-ce0711b9632e@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>
 <dRec0_7eODvQDZ4CmdbSUd2Ch3lvM5od7Meox7nPrmM=.26ed0d8f-572d-4cc4-8fdc-6104b8bd7747@github.com>
 <I7YSW4CzPAgzpjTo7Unli6X7I-tZrxazwrWfph2vYeA=.3ea83e4c-1424-43fb-8ce5-ce0711b9632e@github.com>
Message-ID: <jGEx6rznqrQFaXjyL4c6ckABu15MwS7YZpPaNN6vsGM=.d9e86390-d845-4b3e-b244-32775867074d@github.com>

On Thu, 14 Sep 2023 19:32:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I can look into running a benchmark on this.
>
> A quick measurement suggests that doubling the buffer size to 16384 would increase `read` throughput by more than 15%, and `write` throughput by more than 40%.

That would be a nice additional benefit on top of reducing the direct memory allocations

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326643651

From siddhsql at gmail.com  Fri Sep 15 01:26:33 2023
From: siddhsql at gmail.com (Siddharth Jain)
Date: Thu, 14 Sep 2023 18:26:33 -0700
Subject: OverlappingFileLockException when trying to lock a filechannel
 twice in shared mode
In-Reply-To: <ACC6AA39-EA28-4892-89CD-46B84871B754@oracle.com>
References: <CAPqV3pRYsZhYFZxT5QQq3PsY0bAV8SfpKGPVRxa2zXtJfK71uA@mail.gmail.com>
 <CAPqV3pS+XsJ1Cti=UrV77Gr6p_7ct2gdVX0NM8XQvBNYTmuQ8A@mail.gmail.com>
 <ACC6AA39-EA28-4892-89CD-46B84871B754@oracle.com>
Message-ID: <CAPqV3pRk5xazHT9b7fHb+s6MuWXr3GhJ5UC=70-FWjoGLv2jmQ@mail.gmail.com>

its confusing at best.

https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileLock.html

>A shared lock prevents other concurrently-running programs from acquiring
an overlapping exclusive lock, but does allow them to acquire overlapping
shared locks.

>File locks are held on behalf of the entire Java virtual machine. They are
not suitable for controlling access to a file by multiple threads within
the same virtual machine

so it doesn't specify the behavior within same program and across threads
and what i am finding (for benefit of anyone who comes across this) is that
there is an exception if the same thread tries to lock the channel twice in
shared mode (original email) but there is no exception if two different
threads within same program try to do it.

On Thu, Sep 14, 2023 at 3:28?PM Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> A "concurrently running program? means a separate process. You are
> attempting to acquire two overlapping locks in the *same* process.
>
> Brian
>
> On Sep 14, 2023, at 2:21 PM, Siddharth Jain <siddhsql at gmail.com> wrote:
>
>
> https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/nio/channels/FileLock.html
> A file lock is either *exclusive* or *shared*. A shared lock prevents
> other *concurrently-running programs* from acquiring an overlapping
> exclusive lock, *but does allow them to acquire overlapping shared locks.*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230914/1b1d012d/attachment.htm>

From alanb at openjdk.org  Fri Sep 15 06:41:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 06:41:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
Message-ID: <JvjxbRaJidA13hZ3TLvh2RHxDPc2wRDwTSYXhYQMaZ0=.eb237f46-6c21-4a16-b35c-a2278a91909e@github.com>

On Thu, 14 Sep 2023 22:51:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Read at most DEFAULT_BUFFER_SIZE bytes

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 71:

> 69:             return 0;
> 70: 
> 71:         bb.limit(pos + Integer.min(rem, Streams.DEFAULT_BUFFER_SIZE));

I assume we would end up with a MAX_BUFFER_SIZE that is something like 128k, like we ended up in NioSocketImpl for the same reason. In order words, it's different to the chunk size that is DEFAULT_BUFFER_SIZE today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1326863659

From vtewari at openjdk.org  Fri Sep 15 10:40:40 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Fri, 15 Sep 2023 10:40:40 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
Message-ID: <Pz5RPvA2gFk0ckEWdsEHJsJilVJn7xSGlDI1CHPgh60=.fbed78a7-ede8-4afa-a286-74b68fc65a81@github.com>

On Thu, 14 Sep 2023 22:51:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Read at most DEFAULT_BUFFER_SIZE bytes

test/jdk/java/nio/channels/Channels/ChannelStreamsIO.java line 80:

> 78:             byte[] dst = new byte[SIZE];
> 79:             int n = -1;
> 80:             if ((n = in.read(dst)) != SIZE)

in.read(dst) may return less then the requested(SIZE in this test) ?. Can you please add little bit more descriptive 'RuntimeException' message . It will help to debug issue faster if it fails in future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1327115344

From duke at openjdk.org  Fri Sep 15 11:04:41 2023
From: duke at openjdk.org (Bernd)
Date: Fri, 15 Sep 2023 11:04:41 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <jGEx6rznqrQFaXjyL4c6ckABu15MwS7YZpPaNN6vsGM=.d9e86390-d845-4b3e-b244-32775867074d@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <pY5HbOxgh2pWU8OkyFCZU2hnrzlwbrrvy-dxFmex-OU=.06b26dc8-98fc-4b4d-b331-2cc617c41d6a@github.com>
 <dRec0_7eODvQDZ4CmdbSUd2Ch3lvM5od7Meox7nPrmM=.26ed0d8f-572d-4cc4-8fdc-6104b8bd7747@github.com>
 <I7YSW4CzPAgzpjTo7Unli6X7I-tZrxazwrWfph2vYeA=.3ea83e4c-1424-43fb-8ce5-ce0711b9632e@github.com>
 <jGEx6rznqrQFaXjyL4c6ckABu15MwS7YZpPaNN6vsGM=.d9e86390-d845-4b3e-b244-32775867074d@github.com>
Message-ID: <QtxB0nIYa8RTOTJtujSOgREiyO8vT-1zKzCyBtG3yJ4=.0f34468a-e776-4e5d-852a-e24c27fbf07b@github.com>

On Fri, 15 Sep 2023 00:17:45 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> A quick measurement suggests that doubling the buffer size to 16384 would increase `read` throughput by more than 15%, and `write` throughput by more than 40%.
>
> That would be a nice additional benefit on top of reducing the direct memory allocations

I guess it?s still slower than uncapped. Brian mentioned only 8k vs 16k, not bigger or unconstrained. (And it also depends on the physical drivers below the test system)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1327137145

From alanb at openjdk.org  Fri Sep 15 13:24:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 13:24:41 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
Message-ID: <lr6iKWjmaoXqv1PhG4O8RFOWmtvPp8rNy9wAKNvGl5E=.e60a2069-f30a-4465-af4e-0c1b76bd520f@github.com>

On Wed, 13 Sep 2023 02:32:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Improve file access checking; modify a test; add a test

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 138:

> 136: 
> 137:             Files.deleteIfExists(target);
> 138:         } else if (Files.exists(target))

Looking at again and I think this can be dropped from the cross provider case. Files.copy(InputStream, Path) can optionally replace the target so this only need a delete of the target the the source is a directory. So something like this might be simpler:


@@ -69,6 +71,14 @@ static CopyOptions parse(CopyOption... options) {
             }
             return result;
         }
+
+        CopyOption[] replaceExitingOrEmpty() {
+            if (copyAttributes) {
+                return new CopyOption[] { StandardCopyOption.REPLACE_EXISTING };
+            } else {
+                return new CopyOption[0];
+            }
+        }
     }
 
     /**
@@ -129,18 +139,14 @@ static void copyToForeignTarget(Path source, Path target,
         if (sourceAttrs.isSymbolicLink())
             throw new IOException("Copying of symbolic links not supported");
 
-        // delete target if it exists and REPLACE_EXISTING is specified
-        if (opts.replaceExisting) {
-            Files.deleteIfExists(target);
-        } else if (Files.exists(target))
-            throw new FileAlreadyExistsException(target.toString());
-
         // create directory or copy file
         if (sourceAttrs.isDirectory()) {
+            if (opts.replaceExisting)
+                Files.deleteIfExists(target);
             Files.createDirectory(target);
         } else {
             try (InputStream in = Files.newInputStream(source)) {
-                Files.copy(in, target);
+                Files.copy(in, target, opts.replaceExitingOrEmpty());
             }
         }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327281840

From alanb at openjdk.org  Fri Sep 15 14:14:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 14:14:43 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
Message-ID: <F80dCtgUcEMP20y3SS8GwHwyup_mRT183PasqaBBTHE=.ecb9dd6c-3a73-4808-b6ac-f4270f4d49f8@github.com>

On Wed, 13 Sep 2023 02:32:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Improve file access checking; modify a test; add a test

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 901:

> 899:             // ensure source can be moved
> 900:             try {
> 901:                 access(source, W_OK);

I think W_OK is correct but I wonder if this should move to where ensureEmptyDir is called as that is the additional checks for directories but copying.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327345133

From alanb at openjdk.org  Fri Sep 15 14:24:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 14:24:40 GMT
Subject: RFR: 8315485: (fs) Move java/nio/file/Path/Misc.java tests into
 java/nio/file/Path/PathOps.java [v2]
In-Reply-To: <7XW-cxWPmJr_5SRRrQ4RJY5UZ_pSS8j2K7WZAYO1Fas=.dd4fff03-7bd1-4f8c-8c68-32bf81aaa14d@github.com>
References: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
 <7XW-cxWPmJr_5SRRrQ4RJY5UZ_pSS8j2K7WZAYO1Fas=.dd4fff03-7bd1-4f8c-8c68-32bf81aaa14d@github.com>
Message-ID: <ZMwwE3YDJGFZd5RE60B1QEXWQYOEvIjYX62eALakaNw=.ca108500-292e-4039-817b-c4336c6ebe97@github.com>

On Wed, 6 Sep 2023 15:33:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In the `java/nio/file/Path` tests, add to `PathOps` tests equivalent to those in `Misc` and then remove the latter.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8315485: Fix whitespace errors
>  - 8315485: Refactor equals()

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15572#pullrequestreview-1629068033

From bpb at openjdk.org  Fri Sep 15 15:18:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 15:18:49 GMT
Subject: Integrated: 8315485: (fs) Move java/nio/file/Path/Misc.java tests into
 java/nio/file/Path/PathOps.java
In-Reply-To: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
References: <3BchL_TpqKs57hzXAg6-H41ghQp9eOuZ3vCvqyWO3rA=.44310357-3d7c-4686-95b4-aae04aed471b@github.com>
Message-ID: <3A8VlVihMzxzdLa1p5ertcm0ebOgznUy4WlPURCTFqA=.1af518a2-c4f5-403c-846c-ce1f007dc9e1@github.com>

On Tue, 5 Sep 2023 21:58:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In the `java/nio/file/Path` tests, add to `PathOps` tests equivalent to those in `Misc` and then remove the latter.

This pull request has now been integrated.

Changeset: 8dfde28b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8dfde28b289cbb53173f0ab759156088bbaf74f1
Stats:     149 lines in 2 files changed: 58 ins; 88 del; 3 mod

8315485: (fs) Move java/nio/file/Path/Misc.java tests into java/nio/file/Path/PathOps.java

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Fri Sep 15 15:57:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 15:57:42 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <F80dCtgUcEMP20y3SS8GwHwyup_mRT183PasqaBBTHE=.ecb9dd6c-3a73-4808-b6ac-f4270f4d49f8@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
 <F80dCtgUcEMP20y3SS8GwHwyup_mRT183PasqaBBTHE=.ecb9dd6c-3a73-4808-b6ac-f4270f4d49f8@github.com>
Message-ID: <MiDOUBRNyJ1Rk9Sg-VzMU5_xsHlAb56vKphH8vXfZJ0=.ba0e414f-fed5-4fd6-92c9-1de7f9507d77@github.com>

On Fri, 15 Sep 2023 14:12:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Improve file access checking; modify a test; add a test
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 901:
> 
>> 899:             // ensure source can be moved
>> 900:             try {
>> 901:                 access(source, W_OK);
> 
> I think W_OK is correct but I wonder if this should move to where ensureEmptyDir is called as that is the additional checks for directories but copying.

That does not work. With this change the operation fails in `rename` and the existing target is deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327498227

From bpb at openjdk.org  Fri Sep 15 16:27:39 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 16:27:39 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <lr6iKWjmaoXqv1PhG4O8RFOWmtvPp8rNy9wAKNvGl5E=.e60a2069-f30a-4465-af4e-0c1b76bd520f@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
 <lr6iKWjmaoXqv1PhG4O8RFOWmtvPp8rNy9wAKNvGl5E=.e60a2069-f30a-4465-af4e-0c1b76bd520f@github.com>
Message-ID: <__gPF5_lrenvtjc4TNHZzLWE-y458DXY2f9UH_zNzaQ=.dc8fedc6-7273-4ed9-8033-a73a4c44527d@github.com>

On Fri, 15 Sep 2023 13:21:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Improve file access checking; modify a test; add a test
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 138:
> 
>> 136: 
>> 137:             Files.deleteIfExists(target);
>> 138:         } else if (Files.exists(target))
> 
> Looking at again and I think this can be dropped from the cross provider case. Files.copy(InputStream, Path) can optionally replace the target so this only need a delete of the target the the source is a directory. So something like this might be simpler:
> 
> 
> @@ -69,6 +71,14 @@ static CopyOptions parse(CopyOption... options) {
>              }
>              return result;
>          }
> +
> +        CopyOption[] replaceExitingOrEmpty() {
> +            if (copyAttributes) {
> +                return new CopyOption[] { StandardCopyOption.REPLACE_EXISTING };
> +            } else {
> +                return new CopyOption[0];
> +            }
> +        }
>      }
>  
>      /**
> @@ -129,18 +139,14 @@ static void copyToForeignTarget(Path source, Path target,
>          if (sourceAttrs.isSymbolicLink())
>              throw new IOException("Copying of symbolic links not supported");
>  
> -        // delete target if it exists and REPLACE_EXISTING is specified
> -        if (opts.replaceExisting) {
> -            Files.deleteIfExists(target);
> -        } else if (Files.exists(target))
> -            throw new FileAlreadyExistsException(target.toString());
> -
>          // create directory or copy file
>          if (sourceAttrs.isDirectory()) {
> +            if (opts.replaceExisting)
> +                Files.deleteIfExists(target);
>              Files.createDirectory(target);
>          } else {
>              try (InputStream in = Files.newInputStream(source)) {
> -                Files.copy(in, target);
> +                Files.copy(in, target, opts.replaceExitingOrEmpty());
>              }
>          }

This change looks reasonable, but it causes `CopyAndMove` to fail at line 777 in

* Test: copy regular file, target exists

due to an exception in `Files.copy`:

try (InputStream in = Files.newInputStream(source)) {
    Files.copy(in, target, opts.replaceExistingOrEmpty());
}

The new method `replaceExistingOrEmpty` returns a zero-length array as `copyAttributes` is `false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327530278

From alanb at openjdk.org  Fri Sep 15 16:42:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Sep 2023 16:42:47 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <__gPF5_lrenvtjc4TNHZzLWE-y458DXY2f9UH_zNzaQ=.dc8fedc6-7273-4ed9-8033-a73a4c44527d@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
 <lr6iKWjmaoXqv1PhG4O8RFOWmtvPp8rNy9wAKNvGl5E=.e60a2069-f30a-4465-af4e-0c1b76bd520f@github.com>
 <__gPF5_lrenvtjc4TNHZzLWE-y458DXY2f9UH_zNzaQ=.dc8fedc6-7273-4ed9-8033-a73a4c44527d@github.com>
Message-ID: <lB9mo3mAkhUPCZdcvmDEy44JmHLX3jJfOLVyzX4Wu2U=.49978378-b689-4cca-8042-04a5a1f54244@github.com>

On Fri, 15 Sep 2023 16:25:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 138:
>> 
>>> 136: 
>>> 137:             Files.deleteIfExists(target);
>>> 138:         } else if (Files.exists(target))
>> 
>> Looking at again and I think this can be dropped from the cross provider case. Files.copy(InputStream, Path) can optionally replace the target so this only need a delete of the target the the source is a directory. So something like this might be simpler:
>> 
>> 
>> @@ -69,6 +71,14 @@ static CopyOptions parse(CopyOption... options) {
>>              }
>>              return result;
>>          }
>> +
>> +        CopyOption[] replaceExitingOrEmpty() {
>> +            if (replaceExisting) {
>> +                return new CopyOption[] { StandardCopyOption.REPLACE_EXISTING };
>> +            } else {
>> +                return new CopyOption[0];
>> +            }
>> +        }
>>      }
>>  
>>      /**
>> @@ -129,18 +139,14 @@ static void copyToForeignTarget(Path source, Path target,
>>          if (sourceAttrs.isSymbolicLink())
>>              throw new IOException("Copying of symbolic links not supported");
>>  
>> -        // delete target if it exists and REPLACE_EXISTING is specified
>> -        if (opts.replaceExisting) {
>> -            Files.deleteIfExists(target);
>> -        } else if (Files.exists(target))
>> -            throw new FileAlreadyExistsException(target.toString());
>> -
>>          // create directory or copy file
>>          if (sourceAttrs.isDirectory()) {
>> +            if (opts.replaceExisting)
>> +                Files.deleteIfExists(target);
>>              Files.createDirectory(target);
>>          } else {
>>              try (InputStream in = Files.newInputStream(source)) {
>> -                Files.copy(in, target);
>> +                Files.copy(in, target, opts.replaceExitingOrEmpty());
>>              }
>>          }
>
> This change looks reasonable, but it causes `CopyAndMove` to fail at line 777 in
> 
> * Test: copy regular file, target exists
> 
> due to an exception in `Files.copy`:
> 
> try (InputStream in = Files.newInputStream(source)) {
>     Files.copy(in, target, opts.replaceExistingOrEmpty());
> }
> 
> The new method `replaceExistingOrEmpty` returns a zero-length array as `copyAttributes` is `false`.

There may be a typo, it should be an empty array when replaceExisting (not copyAttributes) is false. The main point is that copy from an input stream to a file already supports REPLACE_EXISTING option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327547600

From bpb at openjdk.org  Fri Sep 15 16:54:38 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 16:54:38 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v5]
In-Reply-To: <lB9mo3mAkhUPCZdcvmDEy44JmHLX3jJfOLVyzX4Wu2U=.49978378-b689-4cca-8042-04a5a1f54244@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <FA4F4G6ez1VX11T8iDD2f64siuhLeNcOvq74SnhOsVo=.185d6980-e27b-4212-9933-d6988631dec4@github.com>
 <lr6iKWjmaoXqv1PhG4O8RFOWmtvPp8rNy9wAKNvGl5E=.e60a2069-f30a-4465-af4e-0c1b76bd520f@github.com>
 <__gPF5_lrenvtjc4TNHZzLWE-y458DXY2f9UH_zNzaQ=.dc8fedc6-7273-4ed9-8033-a73a4c44527d@github.com>
 <lB9mo3mAkhUPCZdcvmDEy44JmHLX3jJfOLVyzX4Wu2U=.49978378-b689-4cca-8042-04a5a1f54244@github.com>
Message-ID: <mh1PfnvmD2EFr-2N_PpEMsNjERjdmR34WekMqo1Tt7U=.c976b2e5-0128-4c1c-9230-8964521da4af@github.com>

On Fri, 15 Sep 2023 16:40:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change looks reasonable, but it causes `CopyAndMove` to fail at line 777 in
>> 
>> * Test: copy regular file, target exists
>> 
>> due to an exception in `Files.copy`:
>> 
>> try (InputStream in = Files.newInputStream(source)) {
>>     Files.copy(in, target, opts.replaceExistingOrEmpty());
>> }
>> 
>> The new method `replaceExistingOrEmpty` returns a zero-length array as `copyAttributes` is `false`.
>
> There may be a typo, it should be an empty array when replaceExisting (not copyAttributes) is false. The main point is that copy from an input stream to a file already supports REPLACE_EXISTING option.

Looks like it was a typo. All `java/nio/file/Files` tests pass with this version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1327560362

From bpb at openjdk.org  Fri Sep 15 17:37:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Sep 2023 17:37:30 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v6]
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>

> Check that the source is readable before deleting the destination.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8073061: Tweak CopyMoveHelper.copyToForeignTarget

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15501/files
  - new: https://git.openjdk.org/jdk/pull/15501/files/ec6c7ddd..8b5f3bcc

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

  Stats: 20 lines in 1 file changed: 10 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15501/head:pull/15501

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

From clanger at openjdk.org  Fri Sep 15 21:48:06 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Sep 2023 21:48:06 GMT
Subject: RFR: 8316387: Exclude more failing multicast tests on AIX after
 JDK-8315651
Message-ID: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>

[JDK-8315651](https://bugs.openjdk.org/browse/JDK-8315651) has removed a facility to hide errors of the type that is described in [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) from the test scaffolding.

Now we see more multicast tests failing on AIX and we should exclude them with reference to [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807).

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

Commit messages:
 - JDK-8316387

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

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

From alanb at openjdk.org  Sat Sep 16 06:49:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Sep 2023 06:49:47 GMT
Subject: RFR: 8316387: Exclude more failing multicast tests on AIX after
 JDK-8315651
In-Reply-To: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
References: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
Message-ID: <aaxRyS6I0ATEv5Zh6Tm2EcS5tG-IEfOgr8N0AZ55XFU=.abdd000f-9ba9-4432-8255-e18ff8b954fc@github.com>

On Fri, 15 Sep 2023 21:40:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> [JDK-8315651](https://bugs.openjdk.org/browse/JDK-8315651) has removed a facility to hide errors of the type that is described in [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) from the test scaffolding.
> 
> Now we see more multicast tests failing on AIX and we should exclude them with reference to [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807).

Looks okay, just surprised there aren't a lot more DatagramChannel tests needing to be excluded.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15770#pullrequestreview-1629915604

From alanb at openjdk.org  Sat Sep 16 15:02:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Sep 2023 15:02:08 GMT
Subject: RFR: 8316391: (zipfs) ZipFileSystem.readFullyAt does not tolerate
 short reads
Message-ID: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>

While looking at another issue, ZipFileSystem.readFullyAt jumped out as not working when the underlying read returns less bytes than expected. There is never a guarantee that reading from a channel will return the expected number of bytes so readFullyAt needs to loop if there is a short read. I've renamed the method as it's really a positional-readNBytes. Test LargeGatheringWrite.java has the same issue so fixed it while in the area.

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

Commit messages:
 - LargeGatheringWrite test has same issue
 - Initial commit

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

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

From clanger at openjdk.org  Sat Sep 16 21:11:46 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 16 Sep 2023 21:11:46 GMT
Subject: RFR: 8316387: Exclude more failing multicast tests on AIX after
 JDK-8315651
In-Reply-To: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
References: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
Message-ID: <qMnNPboThq7HTLcmp3NszY0RFtB7hx7GFsN9IVut_mA=.5451a184-ce73-4e52-823e-7da853f8456a@github.com>

On Fri, 15 Sep 2023 21:40:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> [JDK-8315651](https://bugs.openjdk.org/browse/JDK-8315651) has removed a facility to hide errors of the type that is described in [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) from the test scaffolding.
> 
> Now we see more multicast tests failing on AIX and we should exclude them with reference to [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807).

Thanks for the review, Alan. Those are the additional failing tests that we see. Some others had already been excluded.

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

PR Comment: https://git.openjdk.org/jdk/pull/15770#issuecomment-1722316438

From clanger at openjdk.org  Sat Sep 16 21:11:47 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 16 Sep 2023 21:11:47 GMT
Subject: Integrated: 8316387: Exclude more failing multicast tests on AIX after
 JDK-8315651
In-Reply-To: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
References: <bw75qGf6MFGZpapXe8kJTBEToJfd7PNluOunyxYM_Jc=.bd071e10-8fd3-494c-9027-ea290fb1c8fb@github.com>
Message-ID: <4RDd7RmVs-riaByTSVaTnPfzbwoKlTgMjoxH6eHYAGI=.d0de6846-34d1-4a5b-a9c1-fac3bd1e8e14@github.com>

On Fri, 15 Sep 2023 21:40:03 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> [JDK-8315651](https://bugs.openjdk.org/browse/JDK-8315651) has removed a facility to hide errors of the type that is described in [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) from the test scaffolding.
> 
> Now we see more multicast tests failing on AIX and we should exclude them with reference to [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807).

This pull request has now been integrated.

Changeset: e6241982
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e62419823a06ebd4499c5fadfc1f53a9bc3f71ce
Stats:     16 lines in 1 file changed: 10 ins; 5 del; 1 mod

8316387: Exclude more failing multicast tests on AIX after JDK-8315651

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Sun Sep 17 06:34:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 17 Sep 2023 06:34:50 GMT
Subject: RFR: 8316391: (zipfs) ZipFileSystem.readFullyAt does not tolerate
 short reads
In-Reply-To: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
References: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
Message-ID: <OhoxA4dWBxHisiKdp4MXxiYE2aAqrsiMfGJgoLmBIOg=.a5f36454-0109-4f00-8d4f-718eb320083a@github.com>

On Sat, 16 Sep 2023 09:07:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> While looking at another issue, ZipFileSystem.readFullyAt jumped out as not working when the underlying read returns less bytes than expected. There is never a guarantee that reading from a channel will return the expected number of bytes so readFullyAt needs to loop if there is a short read. I've renamed the method as it's really a positional-readNBytes. Test LargeGatheringWrite.java has the same issue so fixed it while in the area.

The changes look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15772#pullrequestreview-1630045421

From alanb at openjdk.org  Sun Sep 17 08:21:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Sep 2023 08:21:49 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v6]
In-Reply-To: <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
Message-ID: <GktLFQdoXKSqjX57gf034-xUrP1w17qXxComET-TrlE=.94a7a2b5-5d85-4a0e-99ab-214e27cc019d@github.com>

On Fri, 15 Sep 2023 17:37:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Tweak CopyMoveHelper.copyToForeignTarget

test/jdk/java/nio/file/Files/CopyMoveVariations.java line 129:

> 127:             }
> 128: 
> 129:             if (Files.getFileStore(source).supportsFileAttributeView("posix")) {

The `@requires` at the top of the test restricts execution to Linux and macOS for now. I would have thought it's a hard requirement that the file system support POSIX file permissions.

test/jdk/java/nio/file/Files/CopyMoveVariations.java line 135:

> 133:                     Files.setPosixFilePermissions(linkTarget, perms);
> 134:                 else
> 135:                     Files.setPosixFilePermissions(source, perms);

Should this be expanded to cover the permissions of the directory containing the source file, that's the case where the access(2) call may fail because the directory can't be updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1328061248
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1328061472

From lancea at openjdk.org  Sun Sep 17 11:03:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 17 Sep 2023 11:03:39 GMT
Subject: RFR: 8316391: (zipfs) ZipFileSystem.readFullyAt does not tolerate
 short reads
In-Reply-To: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
References: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
Message-ID: <aNlG-cgvySCK3Dy3AJM899VcQ0bYEbxIZTbWTh-4T-A=.6bc04370-dc88-4a4d-b8c9-06c4a5d391b3@github.com>

On Sat, 16 Sep 2023 09:07:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> While looking at another issue, ZipFileSystem.readFullyAt jumped out as not working when the underlying read returns less bytes than expected. There is never a guarantee that reading from a channel will return the expected number of bytes so readFullyAt needs to loop if there is a short read. I've renamed the method as it's really a positional-readNBytes. Test LargeGatheringWrite.java has the same issue so fixed it while in the area.
> 
> Testing: tier1-tier4

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15772#pullrequestreview-1630068892

From lancea at openjdk.org  Sun Sep 17 11:17:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 17 Sep 2023 11:17:30 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v4]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <OeqLNEVS0b5Ni7Tpuxtw8DLXBvLb7STsPH-PEMqmACQ=.dacb09c5-cc99-4abe-96a7-e58bb4b8723f@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

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

 - Merge branch 'master' into JDK-8314891
 - Remove tab(s) from comment
 - Added additional tests, along with additional cleanup and refactoring
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/24b159d8..afc9d7d0

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

  Stats: 89465 lines in 2912 files changed: 37847 ins; 14022 del; 37596 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From alanb at openjdk.org  Sun Sep 17 11:55:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 17 Sep 2023 11:55:48 GMT
Subject: Integrated: 8316391: (zipfs) ZipFileSystem.readFullyAt does not
 tolerate short reads
In-Reply-To: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
References: <BZAXAuWEvtscrKmrL3-4tVlXU15w2ImSINNqe0s15Xs=.365a0fda-2378-4719-977b-2eb125b24bae@github.com>
Message-ID: <Ap-qHl0ABq94pld4k4-XhW0NAbi7OWIbVVVRRudSGIc=.80fc0e03-45f4-44f0-a9f0-197fc9434392@github.com>

On Sat, 16 Sep 2023 09:07:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> While looking at another issue, ZipFileSystem.readFullyAt jumped out as not working when the underlying read returns less bytes than expected. There is never a guarantee that reading from a channel will return the expected number of bytes so readFullyAt needs to loop if there is a short read. I've renamed the method as it's really a positional-readNBytes. Test LargeGatheringWrite.java has the same issue so fixed it while in the area.
> 
> Testing: tier1-tier4

This pull request has now been integrated.

Changeset: f4403296
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f44032969f37948a49e5bd0ed6738aa4d93687da
Stats:     56 lines in 3 files changed: 18 ins; 1 del; 37 mod

8316391: (zipfs) ZipFileSystem.readFullyAt does not tolerate short reads

Reviewed-by: jpai, lancea

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

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

From lancea at openjdk.org  Sun Sep 17 13:35:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 17 Sep 2023 13:35:13 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v5]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <ACWBEA8P8NjA6ejId5pmpqTwDDbiqlFFYiro9MMPEhk=.077e0a09-fe06-4496-a6ec-6793893ac450@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

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

 - Merge branch 'master' into JDK-8314891
 - Merge branch 'master' into JDK-8314891
 - Remove tab(s) from comment
 - Added additional tests, along with additional cleanup and refactoring
 - Clean up some minor formatting issues
 - Additional Zip64 extra header validation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/afc9d7d0..f64a70c3

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

  Stats: 56 lines in 3 files changed: 18 ins; 1 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From Alan.Bateman at oracle.com  Sun Sep 17 15:32:42 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 17 Sep 2023 16:32:42 +0100
Subject: Files.copy(InputStream, Path, CopyOption...) can fail with OOM if
 direct memory is limited
In-Reply-To: <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
References: <D3EFDB1F-13D8-4633-9831-65A998554FF8@paul.kungfoocoder.org>
 <c168f036-81f1-c4fa-5eec-3d5580a79918@oracle.com>
 <A7C23960-343F-4AC2-897A-C1338E298261@paul.kungfoocoder.org>
Message-ID: <590263dd-a3b2-028d-cc7f-5744110c48e5@oracle.com>



On 12/09/2023 22:39, github at paul.kungfoocoder.org wrote:
> Agreed. My question is what is the next step now that I have 
> identified this problem? Do others agree that this is something that 
> should be fixed? What can I do to move this forward?
>
We have to proceed with caution. You pointed to IOUtil.write in your 
original mail but changing ityo? limit the size of the temporary direct 
buffer will likely break existing code/usage that don't correct checking 
the return value. We found two cases in the JDK code and it seems likely 
are more in the wider eco system. Limiting in the adaptor classes (the 
classes returned by Channels.newInputStream and newOutputStream) reduces 
the impact but we still need to be cautious as there may be code that 
reads from an input stream and isn't checking for "short reads". For the 
specific scenario here then it may be that BIS.transferTo just needs to 
be changed to write chunks to the target output stream.

-Alan



From alanb at openjdk.org  Mon Sep 18 07:40:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Sep 2023 07:40:39 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v6]
In-Reply-To: <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
Message-ID: <tJMsB1gB208awcsh6X2pw-7NU9gHN41JRiQ_1XWKpWU=.7a844358-37da-4b55-8a3e-45e7c211a7c2@github.com>

On Fri, 15 Sep 2023 17:37:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Tweak CopyMoveHelper.copyToForeignTarget

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 901:

> 899:             // ensure source can be moved
> 900:             try {
> 901:                 access(source, W_OK);

One small suggestion here is to move this to L900, after UnixFileAttributes.get, as that will avoid the exception handling and means the examination of the source is in one place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1328341604

From mbaesken at openjdk.org  Mon Sep 18 09:07:42 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 18 Sep 2023 09:07:42 GMT
Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to
 joinGroup
In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
Message-ID: <oZ5TBkFwhNu7FoATsxDIIBMU2qTQI8XBzzD0_VbMGaw=.e0c82b65-523e-40b2-887f-6702be5f718b@github.com>

On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari <duke at openjdk.org> wrote:

> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
> 
> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
> 
> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
> 
> 
> 
> 
> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

With this PR added to our build/test queue we noticed a number of additional test failures **cross platform** .
Examples
java/net/MulticastSocket/JoinLeave.java
java/net/MulticastSocket/MulticastAddresses.java

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

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1723017139

From pminborg at openjdk.org  Mon Sep 18 11:09:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Sep 2023 11:09:05 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in DirectByteBuffer.Deallocator
Message-ID: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>

This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.

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

Commit messages:
 - Make fields final

Changes: https://git.openjdk.org/jdk/pull/15784/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316337
  Stats: 16 lines in 2 files changed: 4 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15784/head:pull/15784

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

From pminborg at openjdk.org  Mon Sep 18 11:30:28 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Sep 2023 11:30:28 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v2]
In-Reply-To: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
Message-ID: <wqI0jMmEDJZvvdlZ_H7_uidD909KH2Cmfp9kvL3zd3E=.32e04997-c956-4dd9-b965-12cfbab96af9@github.com>

> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Make the unmapper of MappedByteBuffer safe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15784/files
  - new: https://git.openjdk.org/jdk/pull/15784/files/83a30d3e..e8ed778b

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

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

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

From alanb at openjdk.org  Mon Sep 18 11:52:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Sep 2023 11:52:41 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v2]
In-Reply-To: <wqI0jMmEDJZvvdlZ_H7_uidD909KH2Cmfp9kvL3zd3E=.32e04997-c956-4dd9-b965-12cfbab96af9@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <wqI0jMmEDJZvvdlZ_H7_uidD909KH2Cmfp9kvL3zd3E=.32e04997-c956-4dd9-b965-12cfbab96af9@github.com>
Message-ID: <LIaYsE2yItARvP0_IqNJwra2VB0NSD99iJzqsuYRUak=.1a003261-7b6b-42d1-b9fd-82cc5c7bbed8@github.com>

On Mon, 18 Sep 2023 11:30:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the unmapper of MappedByteBuffer safe

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 85:

> 83:         private final long size;
> 84:         private final int capacity;
> 85:         private volatile boolean completed;

Using a volatile flag here okay but something like "deallocated" might be clearer than "completed". While you there, maybe remove the spurious blank left at L81, it doesn't help readability in this tiny class.

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 125:

> 123: 
> 124:     private final class BufferUnmapperProxy implements UnmapperProxy {
> 125: 

This blank line can be removed too,

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

> 1163:         private final FileDescriptor fd;
> 1164:         private final int pagePosition;
> 1165:         private volatile boolean completed;

"unmapped" would be better here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328592780
PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328593381
PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328594504

From pminborg at openjdk.org  Mon Sep 18 12:19:42 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Sep 2023 12:19:42 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
Message-ID: <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>

> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename boolean variable and reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15784/files
  - new: https://git.openjdk.org/jdk/pull/15784/files/e8ed778b..64e94380

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

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

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

From lancea at openjdk.org  Mon Sep 18 13:12:31 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 18 Sep 2023 13:12:31 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v6]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <vocnPgjlixB4VdKbF1rA8BMZfDHGnqfbgg_uyGn1a6Y=.2d934f83-12ff-4203-ae7f-788d358ee8b7@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Revamp isZip64ExtBlockSizeValid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/f64a70c3..bbc5325d

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

  Stats: 61 lines in 3 files changed: 14 ins; 13 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15650/head:pull/15650

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

From lancea at openjdk.org  Mon Sep 18 13:17:25 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 18 Sep 2023 13:17:25 GMT
Subject: RFR: 8314891: Additional Zip64 extra header validation [v7]
In-Reply-To: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
References: <YkC5qi-66NinohgTcDC6O4xj-AlDVFoZ4tFB1SC3ILU=.9b2fe35a-98b3-4b3d-b949-099aa7b4a133@github.com>
Message-ID: <5i8oE7FeOG7W7B2C5jqyKuGNJ_EHf9POIox606GDhzs=.faa3ffd1-6fa6-4a40-984b-a6557e685c0e@github.com>

> Please review this PR which improves the Zip64 extra header validation:
> 
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0xFFFFFFFF
> -- disk starting number is set to 0xFFFF
> 
> - We have a valid size for the Zip64 extra header but we are missing the csize or loc fields if they are expected to be part of the header
> 
> Mach5 tiers 1-3 are clean

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add missing space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15650/files
  - new: https://git.openjdk.org/jdk/pull/15650/files/bbc5325d..208a5ecc

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

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

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

From jvernee at openjdk.org  Mon Sep 18 14:17:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 14:17:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>

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

  Avoid eager use of LibFallback in FallbackLinker static block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/e68b95c1..1f3248df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=20-21

  Stats: 62 lines in 1 file changed: 26 ins; 24 del; 12 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

From jvernee at openjdk.org  Mon Sep 18 14:17:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Sep 2023 14:17:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v21]
In-Reply-To: <zWVa5Ac4J4t_2qg1I-8YEiGB-6hmAjAazCkfgK6xg-Q=.a26b791f-b79e-467b-b302-c287ff48c350@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u__LniO_3mS-93WVTcYqKz76HZsC96Qu3Ew9gYWeQ94=.2a787c3b-2d6c-42c1-97b4-b9e3c6ce2e06@github.com>
 <zWVa5Ac4J4t_2qg1I-8YEiGB-6hmAjAazCkfgK6xg-Q=.a26b791f-b79e-467b-b302-c287ff48c350@github.com>
Message-ID: <rPYrRmVqFwzG-_kcHJesSPEaG8Y9ot0BEL7-88JqvPU=.950984fe-b7d0-4368-ab0b-1790e29472d0@github.com>

On Wed, 13 Sep 2023 19:43:53 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add missing space + reflow lines
>>  - Fix typo
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 311:
> 
>> 309:         };
>> 310: 
>> 311:         CANONICAL_LAYOUTS = Map.ofEntries(
> 
> `LibFallback::wcharSize()` and?other?getters for?`LibFallback.NativeConstants`?fields can?throw an?error when?`LibFallback.SUPPORTED` is?`false` due?to the?`fallbackLinker`?library not?being?present, so?this static?initializer should?be?made into?a?method?instead:
> Suggestion:
> 
>     static final Map<String, MemoryLayout> CANONICAL_LAYOUTS = initCanonicalLayouts();
> 
>     private static Map<String, MemoryLayout> initCanonicalLayouts() {
>         if (!isSupported()) {
>             return null;
>         }
> 
>         int wchar_size = LibFallback.wcharSize();
>         MemoryLayout wchartLayout = switch(wchar_size) {
>             case 2 -> JAVA_CHAR; // prefer JAVA_CHAR
>             default -> FFIType.layoutFor(wchar_size);
>         };
> 
>         return Map.ofEntries(

Good catch! I've chosen a slightly different solution though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1328794993

From liach at openjdk.org  Mon Sep 18 14:34:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Sep 2023 14:34:45 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
Message-ID: <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>

On Mon, 18 Sep 2023 12:19:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename boolean variable and reformat

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 96:

> 94:                 return;
> 95:             }
> 96:             deallocated = true;

Shouldn't this be an atomic compareAndSet instead? Thread A can read deallocated and pause before the field write, then thread B read deallocated, continue to set the field. There will be a double free when thread A resumes.

src/java.base/share/classes/java/nio/MappedByteBuffer.java line 123:

> 121:                     @Override
> 122:                     public long address() {
> 123:                         return address;

We can just declare a `final long address = MappedByteBuffer.this.address;` instead of a huge refactor, right?

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

> 1198:             if (address == 0 || unmapped)
> 1199:                 return;
> 1200:             unmapped = true;

Same question

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328816701
PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328820849
PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328818097

From alanb at openjdk.org  Mon Sep 18 14:57:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Sep 2023 14:57:40 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
Message-ID: <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>

On Mon, 18 Sep 2023 14:28:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Shouldn't this be an atomic compareAndSet instead? Thread A can read deallocated and pause before the field write, then thread B read deallocated, continue to set the field. There will be a double free when thread A resumes.

Deallocator is the cleaner action so it should only ever be run once by the cleaner thread. There is a back door via Unsafe.invokeCleaner for freeing a buffer potentially in use but the cleaner action should still only be invoked once.  The "Paranoia" comment and guarding against being called again may date back to the older cleaner code, requires a bit of digging to see if (and the flag) can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328857155

From liach at openjdk.org  Mon Sep 18 15:35:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Sep 2023 15:35:40 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
 <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
Message-ID: <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>

On Mon, 18 Sep 2023 14:54:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 96:
>> 
>>> 94:                 return;
>>> 95:             }
>>> 96:             deallocated = true;
>> 
>> Shouldn't this be an atomic compareAndSet instead? Thread A can read deallocated and pause before the field write, then thread B read deallocated, continue to set the field. There will be a double free when thread A resumes.
>
>> Shouldn't this be an atomic compareAndSet instead? Thread A can read deallocated and pause before the field write, then thread B read deallocated, continue to set the field. There will be a double free when thread A resumes.
> 
> Deallocator is the cleaner action so it should only ever be run once by the cleaner thread. There is a back door via Unsafe.invokeCleaner for freeing a buffer potentially in use but the cleaner action should still only be invoked once.  The "Paranoia" comment and guarding against being called again may date back to the older cleaner code, requires a bit of digging to see if (and the flag) can be removed.

If only one cleaner thread runs, can we just safely assume it is run only once and simply remove the `deallocated` check, which only defends against some, but not all, of those erroneous situations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1328912359

From alanb at openjdk.org  Mon Sep 18 16:46:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Sep 2023 16:46:40 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
 <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
 <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>
Message-ID: <mXjJam58qVBNBCVeEzBX5Ue6rty8ddA4u9NHZmgZ2Zw=.72874d39-da39-452b-a60f-8fbdac46fa86@github.com>

On Mon, 18 Sep 2023 15:32:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> If only one cleaner thread runs, can we just safely assume it is run only once and simply remove the `deallocated` check, which only defends against some, but not all, of those erroneous situations?

Cleaner specifies that it is run once so yes, I think flag can be dropped, as well as checking if the address is 0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1329012226

From bpb at openjdk.org  Mon Sep 18 17:16:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Sep 2023 17:16:29 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v7]
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <LkZrurP9lQy0X8ZJQze7BbzJnydpp-5UQkq12tIbWzQ=.0611bcbb-185f-4df1-b67a-f0f1d7ac859f@github.com>

> Check that the source is readable before deleting the destination.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8073061: Check for POSIX permission support at top level of test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15501/files
  - new: https://git.openjdk.org/jdk/pull/15501/files/8b5f3bcc..cd644e46

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

  Stats: 48 lines in 2 files changed: 31 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15501/head:pull/15501

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

From bpb at openjdk.org  Mon Sep 18 17:16:34 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Sep 2023 17:16:34 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v6]
In-Reply-To: <tJMsB1gB208awcsh6X2pw-7NU9gHN41JRiQ_1XWKpWU=.7a844358-37da-4b55-8a3e-45e7c211a7c2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
 <tJMsB1gB208awcsh6X2pw-7NU9gHN41JRiQ_1XWKpWU=.7a844358-37da-4b55-8a3e-45e7c211a7c2@github.com>
Message-ID: <XBQZwEKlH4amYKHE8hu07rn-Pc_qA3pZdRcMIDQ5UJg=.e7f33db1-4ae1-4057-84ec-a399daf9c784@github.com>

On Mon, 18 Sep 2023 07:37:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Tweak CopyMoveHelper.copyToForeignTarget
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 901:
> 
>> 899:             // ensure source can be moved
>> 900:             try {
>> 901:                 access(source, W_OK);
> 
> One small suggestion here is to move this to L900, after UnixFileAttributes.get, as that will avoid the exception handling and means the examination of the source is in one place.

Good idea. So changed in cd644e46fed22a1f8b4932b8ee5b54626134ad18.

> test/jdk/java/nio/file/Files/CopyMoveVariations.java line 129:
> 
>> 127:             }
>> 128: 
>> 129:             if (Files.getFileStore(source).supportsFileAttributeView("posix")) {
> 
> The `@requires` at the top of the test restricts execution to Linux and macOS for now. I would have thought it's a hard requirement that the file system support POSIX file permissions.

Moved requirement to top level in cd644e46fed22a1f8b4932b8ee5b54626134ad18. The `@requires` remains as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1329048318
PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1329048004

From bchristi at openjdk.org  Mon Sep 18 19:11:44 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 18 Sep 2023 19:11:44 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <mXjJam58qVBNBCVeEzBX5Ue6rty8ddA4u9NHZmgZ2Zw=.72874d39-da39-452b-a60f-8fbdac46fa86@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
 <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
 <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>
 <mXjJam58qVBNBCVeEzBX5Ue6rty8ddA4u9NHZmgZ2Zw=.72874d39-da39-452b-a60f-8fbdac46fa86@github.com>
Message-ID: <WgIpohzPcTVCJCE2bpm_FMwGVKUAHpnoK6xGcAS2Wvk=.499703ce-a123-40e2-8778-d15f0da1c9fb@github.com>

On Mon, 18 Sep 2023 16:44:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If only one cleaner thread runs, can we just safely assume it is run only once and simply remove the `deallocated` check, which only defends against some, but not all, of those erroneous situations?
>
>> If only one cleaner thread runs, can we just safely assume it is run only once and simply remove the `deallocated` check, which only defends against some, but not all, of those erroneous situations?
> 
> Cleaner specifies that it is run once so yes, I think flag can be dropped, as well as checking if the address is 0.

`address` can't be 0 if asserts a enabled. Might `address` be 0 if asserts **_aren't_** enabled?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1329168242

From dvb.soln at gmail.com  Mon Sep 18 20:36:16 2023
From: dvb.soln at gmail.com (Didac Vega Bru)
Date: Mon, 18 Sep 2023 22:36:16 +0200
Subject: SocketChannel connect blocks in non-blocking mode
Message-ID: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>

Hello,

I typically use SocketChannel using blocking mode but lately I was 
trying to use non-blocking operations. The issue I find is that, 
according to the javadoc for the connect method of SocketChannel, I 
would expect the method to return immediately either with a true, false 
or fail fast.

SO, trying a piece of code like the following:

 ? var socket = SocketChannel.open();
 ? socket.configureBlocking(false);
 ? socket.connect(new InetSocketAddress("non.existing.address", 1111));

It turns out that the method does not return immediately but blocks 
until it throws (the expected) UnresolvedAddressException. This can take 
some time, specially if DNS is badly configured.

|? Exception java.nio.channels.UnresolvedAddressException
|??????? at Net.checkAddress (Net.java:149)
|??????? at Net.checkAddress (Net.java:157)
|??????? at SocketChannelImpl.checkRemote (SocketChannelImpl.java:816)
|??????? at SocketChannelImpl.connect (SocketChannelImpl.java:839)
| ???? at (#4:1)

Looking at the code for the connect method in SocketChannelImpl, one can 
find that the first statement of the method is

 ?? @Override
 ? public boolean connect(SocketAddress remote) throws IOException {
 ????? SocketAddress sa = checkRemote(remote);
 ????? try {
 ?? ????? ...

So, effectively, the address name resolution is performed always blocking.

Now the question is, I would expect that in non-blocking mode always 
return immediately, and catch all non-immediate possible exceptions 
later with a call to finishConnect (which name resolution would be part 
of). Therefore is this like this for some technical reason? And in that 
case shouldn't the javadoc explicitly point this out?

Thank you,

Didac V.


From ecki at zusammenkunft.net  Mon Sep 18 21:28:21 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 18 Sep 2023 23:28:21 +0200
Subject: SocketChannel connect blocks in non-blocking mode
In-Reply-To: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>
References: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>
Message-ID: <29D54560-9D50-014B-9760-BDB3599979CC@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230918/31cbd474/attachment.htm>

From bpb at openjdk.org  Mon Sep 18 21:55:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Sep 2023 21:55:21 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316156: Revert Channel*Stream changes; add BAIS changes; replace test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15733/files
  - new: https://git.openjdk.org/jdk/pull/15733/files/894d83ac..7ee65b90

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

  Stats: 262 lines in 7 files changed: 123 ins; 128 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15733/head:pull/15733

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

From bpb at openjdk.org  Mon Sep 18 21:55:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Sep 2023 21:55:24 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
Message-ID: <TwboAdbfcMJC71YU_izaoGksfpwOqWeD3uPBTwvYkjE=.b0167b7d-1edb-46cf-ad34-5384aeffb3f7@github.com>

On Thu, 14 Sep 2023 22:51:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Read at most DEFAULT_BUFFER_SIZE bytes

In 7ee65b90fc6c8e48383a1f2c15626013529f6c3b the `Channel{In,Out}putStream` changes are reverted and similar changes are implemented in `transferTo` for `BufferedInputStream` and `ByteArrayInputStream`. In retrospect, I doubt that the `BufferedInputStream` changes and concomitant test code are needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1724505673

From dvb.soln at gmail.com  Mon Sep 18 21:59:33 2023
From: dvb.soln at gmail.com (Didac Vega Bru)
Date: Mon, 18 Sep 2023 23:59:33 +0200
Subject: SocketChannel connect blocks in non-blocking mode
In-Reply-To: <29D54560-9D50-014B-9760-BDB3599979CC@hxcore.ol>
References: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>
 <29D54560-9D50-014B-9760-BDB3599979CC@hxcore.ol>
Message-ID: <ef5bccf8-117f-34e3-93cc-73714bf11d9f@gmail.com>

Hello Bernd,

thank you for your answer. I agree that it is logical that non-blocking 
operation refers only to the actual socket operation.

I guess that I missed the fact that InetSocketAddress is the actual 
object doing the actual name resolution and therefore I can do it 
separately.

Best regards

Didac V.


On 18/09/2023 23:28, Bernd wrote:
> The non-blocking refers only to socket operations, resolving the 
> address is logically outside (it helps to think about C API I guess 
> where the connect gets a resolved address). If you want to async 
> resolve the address you would have to do that separetly (or do it in 
> its own thread since async resolvers are tricky)
>
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20230918/59ad83a8/attachment-0001.htm>

From liach at openjdk.org  Tue Sep 19 00:58:38 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 00:58:38 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <WgIpohzPcTVCJCE2bpm_FMwGVKUAHpnoK6xGcAS2Wvk=.499703ce-a123-40e2-8778-d15f0da1c9fb@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
 <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
 <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>
 <mXjJam58qVBNBCVeEzBX5Ue6rty8ddA4u9NHZmgZ2Zw=.72874d39-da39-452b-a60f-8fbdac46fa86@github.com>
 <WgIpohzPcTVCJCE2bpm_FMwGVKUAHpnoK6xGcAS2Wvk=.499703ce-a123-40e2-8778-d15f0da1c9fb@github.com>
Message-ID: <NkYed-FU2HRo5xOtmsx52K30fcBYM_-yJ9AfWLpt95c=.e90f0273-aac7-4ddd-bb4e-b170aee05467@github.com>

On Mon, 18 Sep 2023 19:09:07 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>>> If only one cleaner thread runs, can we just safely assume it is run only once and simply remove the `deallocated` check, which only defends against some, but not all, of those erroneous situations?
>> 
>> Cleaner specifies that it is run once so yes, I think flag can be dropped, as well as checking if the address is 0.
>
> `address` can't be 0 if asserts a enabled. Might `address` be 0 if asserts **_aren't_** enabled?

This constructor is only used from DirectXBuffer constructors (line 142), and the passed address is the return value of `Unsafe.allocateMemory` (line 129). We can trust `address` as long as we trust the unsafe method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1329428912

From naoto at openjdk.org  Tue Sep 19 01:10:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 01:10:09 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
Message-ID: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>

Fixed the failing (well, false-positive) test case. Made the following changes to the test:

- Corrected the path to the mapping files directory
- Made sure to fail if the directory path is incorrect
- Took care of `GB18030` alias, which is dynamically derived at runtime
- Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
- Excluded other failing tests for IBM charsets that do not have map files.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/15807/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310631
  Stats: 20 lines in 2 files changed: 14 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15807.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15807/head:pull/15807

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

From pminborg at openjdk.org  Tue Sep 19 06:33:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Sep 2023 06:33:08 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v4]
In-Reply-To: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
Message-ID: <RbpFtz4bk7G3bELJ_5BhHKYvv9GO0GbMhcnpKjaELZs=.04e86da3-21da-4534-9e22-95690e950f01@github.com>

> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Make unmappers truly immutable
 - Revert to anonymous UmapperProxy class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15784/files
  - new: https://git.openjdk.org/jdk/pull/15784/files/64e94380..af043d02

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

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

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

From alanb at openjdk.org  Tue Sep 19 06:37:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 06:37:39 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v3]
In-Reply-To: <NkYed-FU2HRo5xOtmsx52K30fcBYM_-yJ9AfWLpt95c=.e90f0273-aac7-4ddd-bb4e-b170aee05467@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <u4Mqo-EDwtnFSmhaIxB2G7iKpCr8_TiPbzNJrOLsrSM=.e859ba54-4955-4dbc-93a6-ec44228d070d@github.com>
 <t6k7769r4vk_ZG4V_GJ8sTJBOBmTylM4rlxtQdIPNog=.b594c374-1a48-4ed4-8d3e-361aa9165d35@github.com>
 <7PtpEwhUw8-w6e4IyAcaohLmVb5v2fcd0vsmv2rzvF4=.6daa5f2e-ea85-4146-a7f0-a6a3a49b0a41@github.com>
 <rMSQuifysKW8uq670pCbWcxeRScPIlhrkRDIgVoq46Y=.ba9e8729-f9e6-4823-aa11-5674230aac14@github.com>
 <mXjJam58qVBNBCVeEzBX5Ue6rty8ddA4u9NHZmgZ2Zw=.72874d39-da39-452b-a60f-8fbdac46fa86@github.com>
 <WgIpohzPcTVCJCE2bpm_FMwGVKUAHpnoK6xGcAS2Wvk=.499703ce-a123-40e2-8778-d15f0da1c9fb@github.com>
 <NkYed-FU2HRo5xOtmsx52K30fcBYM_-yJ9AfWLpt95c=.e90f0273-aac7-4ddd-bb4e-b170aee05467@github.com>
Message-ID: <ZQ9iWdu1Rx3RhBW-YhVLdZfpfO1Pjg_PbDqbOCQN0hk=.d29a6428-3c12-4a64-9ff1-80c6e501d93f@github.com>

On Tue, 19 Sep 2023 00:56:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `address` can't be 0 if asserts a enabled. Might `address` be 0 if asserts **_aren't_** enabled?
>
> This constructor is only used from DirectXBuffer constructors (line 142), and the passed address is the return value of `Unsafe.allocateMemory` (line 129). We can trust `address` as long as we trust the unsafe method.

> `address` can't be 0 if asserts a enabled. Might `address` be 0 if asserts **_aren't_** enabled?

No, the address is always non-0. The assert is good, the check if it's 0 can be removed. If you allocateDirect(0) then it will adjusted to allocate 1 byte so the address is non-0.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1329637509

From Alan.Bateman at oracle.com  Tue Sep 19 07:36:56 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Sep 2023 08:36:56 +0100
Subject: SocketChannel connect blocks in non-blocking mode
In-Reply-To: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>
References: <ec426dd2-e79f-9065-9b70-dd50eb4725f4@gmail.com>
Message-ID: <cc36d81f-dbf4-7544-646d-c1cb98ad7c82@oracle.com>



On 18/09/2023 21:36, Didac Vega Bru wrote:
> Hello,
>
> I typically use SocketChannel using blocking mode but lately I was 
> trying to use non-blocking operations. The issue I find is that, 
> according to the javadoc for the connect method of SocketChannel, I 
> would expect the method to return immediately either with a true, 
> false or fail fast.
>
> SO, trying a piece of code like the following:
>
> ? var socket = SocketChannel.open();
> ? socket.configureBlocking(false);
> ? socket.connect(new InetSocketAddress("non.existing.address", 1111));
>
> It turns out that the method does not return immediately but blocks 
> until it throws (the expected) UnresolvedAddressException. This can 
> take some time, specially if DNS is badly configured.
>
> |? Exception java.nio.channels.UnresolvedAddressException
> |??????? at Net.checkAddress (Net.java:149)
> |??????? at Net.checkAddress (Net.java:157)
> |??????? at SocketChannelImpl.checkRemote (SocketChannelImpl.java:816)
> |??????? at SocketChannelImpl.connect (SocketChannelImpl.java:839)
> | ???? at (#4:1)
>

SocketChannel.connect is specified to throw UAE if the socket address is 
unresolved.? So as others said, creating an InetSocketAddress with a 
host name and port will attempt to resolve the host name, that's where 
you are seeing the delay.

-Alan

From alanb at openjdk.org  Tue Sep 19 07:44:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 07:44:40 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
Message-ID: <NHdyBKmCyEQxuIInlma4d6J1yoMApZxKe2rtvDVqIgc=.3d1ad380-a533-4538-8848-a1ad4b6120a7@github.com>

On Mon, 18 Sep 2023 21:55:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert Channel*Stream changes; add BAIS changes; replace test

Changing BAIS and BIS is good as it avoids the behavioural change that CIS.read may do a short read. The updates look okay but I think we'll need to expand the test for BIS.transferTo for cases where the BIS is created with a buffer size > 128k. Confining the change to just BAIS and not touching BIS is okay too.

One other thing is that the JBS issue and PR title/description are now out of date so probably should fix those up to avoid any confusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1724988621

From alanb at openjdk.org  Tue Sep 19 07:58:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 07:58:39 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v4]
In-Reply-To: <RbpFtz4bk7G3bELJ_5BhHKYvv9GO0GbMhcnpKjaELZs=.04e86da3-21da-4534-9e22-95690e950f01@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <RbpFtz4bk7G3bELJ_5BhHKYvv9GO0GbMhcnpKjaELZs=.04e86da3-21da-4534-9e22-95690e950f01@github.com>
Message-ID: <WfBWV2Qe9P-o8N-rQyVOEI909ee3MUdTc_yDX34RNlQ=.68d807ef-c4ea-4562-a827-d86d6def3a75@github.com>

On Tue, 19 Sep 2023 06:33:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make unmappers truly immutable
>  - Revert to anonymous UmapperProxy class

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15784#pullrequestreview-1632644304

From liach at openjdk.org  Tue Sep 19 08:49:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Sep 2023 08:49:45 GMT
Subject: RFR: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator [v4]
In-Reply-To: <RbpFtz4bk7G3bELJ_5BhHKYvv9GO0GbMhcnpKjaELZs=.04e86da3-21da-4534-9e22-95690e950f01@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
 <RbpFtz4bk7G3bELJ_5BhHKYvv9GO0GbMhcnpKjaELZs=.04e86da3-21da-4534-9e22-95690e950f01@github.com>
Message-ID: <H9KsX2IQke4lAAeC_BoC930emczF_TWv3-UgYpK-CA0=.8f0a3908-e899-4fbf-afa7-6c690d7c60ec@github.com>

On Tue, 19 Sep 2023 06:33:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make unmappers truly immutable
>  - Revert to anonymous UmapperProxy class

Nice cleanup.

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

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/15784#pullrequestreview-1632740593

From duke at openjdk.org  Tue Sep 19 09:41:41 2023
From: duke at openjdk.org (Paul Wagland)
Date: Tue, 19 Sep 2023 09:41:41 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v4]
In-Reply-To: <JvjxbRaJidA13hZ3TLvh2RHxDPc2wRDwTSYXhYQMaZ0=.eb237f46-6c21-4a16-b35c-a2278a91909e@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <mskEY08MlBu04CeopE_fUuaMmTbuVzd1xapxNoeBuCs=.7b71c1ca-fec5-43b9-b387-c591709eba42@github.com>
 <JvjxbRaJidA13hZ3TLvh2RHxDPc2wRDwTSYXhYQMaZ0=.eb237f46-6c21-4a16-b35c-a2278a91909e@github.com>
Message-ID: <Z3BMLIdCyDF06tZlae3Wb_18eOs9rEOiD3LKlkEQyFc=.28274a1c-d514-4879-a53a-6d7a3af8948c@github.com>

On Fri, 15 Sep 2023 06:38:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316156: Read at most DEFAULT_BUFFER_SIZE bytes
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 71:
> 
>> 69:             return 0;
>> 70: 
>> 71:         bb.limit(pos + Integer.min(rem, Streams.DEFAULT_BUFFER_SIZE));
> 
> I assume we would end up with a MAX_BUFFER_SIZE that is something like 128k, like we ended up in NioSocketImpl for the same reason. In order words, it's different to the chunk size that is DEFAULT_BUFFER_SIZE today.

FWIW, getting back to the reason that this was created in the first place, namely that it is possible to limit `MaxDirectBufferSize`, ideally this limit could be dependent on how much is actually available in the system. `Bits` doesn't currently have any way to expose that. In the scenario that I was dealing with, I had 28M of direct buffer, but the system was trying to allocate (roughly) 62M, and that didn't work. So limiting to 128K would still work perfectly in that scenario.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15733#discussion_r1327087661

From duke at openjdk.org  Tue Sep 19 09:48:39 2023
From: duke at openjdk.org (Paul Wagland)
Date: Tue, 19 Sep 2023 09:48:39 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
Message-ID: <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>

On Mon, 18 Sep 2023 21:55:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert Channel*Stream changes; add BAIS changes; replace test

> In [7ee65b9](https://github.com/openjdk/jdk/commit/7ee65b90fc6c8e48383a1f2c15626013529f6c3b) the `Channel{In,Out}putStream` changes are reverted and similar changes are implemented in `transferTo` for `BufferedInputStream` and `ByteArrayInputStream`. In retrospect, I doubt that the `BufferedInputStream` changes and concomitant test code are needed.

Doesn't this just fix only the reported problem though? If there is a InputStream out there that that can also drop a large buffer in, or even if there is code that just does a `channelOutputStream.write(largeBuffer)`, that this will still fail?

The main issue that I had when I reported the problem is that I can no longer safely use `Files.copy`, since it relies on the passedInputStream only doing "small" writes, at least in the face of a limited DirectMemory allocation. This fixes the particular InputStream that I was using, but doesn't fix the generic problem, which means that Files.copy is _still_ unsafe?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1725161992

From alanb at openjdk.org  Tue Sep 19 10:14:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 10:14:42 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
Message-ID: <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>

On Tue, 19 Sep 2023 09:37:39 GMT, Paul Wagland <duke at openjdk.org> wrote:

> Doesn't this just fix only the reported problem though? If there is a InputStream out there that that can also drop a large buffer in, or even if there is code that just does a `channelOutputStream.write(largeBuffer)`, that this will still fail?
> 
> The main issue that I had when I reported the problem is that I can no longer safely use `Files.copy`, since it relies on the passedInputStream only doing "small" writes, at least in the face of a limited DirectMemory allocation. This fixes the particular InputStream that I was using, but doesn't fix the generic problem, which means that Files.copy is _still_ unsafe?

There's a compatibility impact to changing the channel read/write implementations to limit direct buffer usage when called with a heap based ByteBuffer that contains a large number of bytes. We have to be very cautious about changing anything there as it will break existing broken code that assumes a short read/write is not possible. We found two cases in the JDK, one is fixed, the other is WIP. Changing the adaptor class used by Channels.newInputStream has the same concern. I talked to @bplb off-list about this and we agreed that it requires a lot more thinking about changing anything.

As regards Files.copy(InputStream, Path). It uses the input stream's transferTo method to transfer the bytes to the target file. It could be changed to write in chunks or the input streams that have all bytes in the heap could write in chunks. One or both is okay and doesn't have compatibility concerns.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1725217098

From alanb at openjdk.org  Tue Sep 19 10:37:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 10:37:41 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
 <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
 <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>
 <35Ua-4ysRSGF9mUkisetSdeoeXYXpG_pURTnCw7i2xw=.92d19c93-50b0-4ff5-95dd-ce199dad80f2@github.com>
Message-ID: <SsJQUHPYl-0RvpAPy_6u7P2OOT35I8IDrlRRcp66Rk0=.cb415415-95df-44bb-8e07-85022e83dbe7@github.com>

On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
>> 
>> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.
>
>> > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
>> 
>> Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.
> 
> I think it's useful if trying to trace the calls (i.e. set to 0ms).  Apparently the security manager was being used for that by some.

> @tprinzing 
> Your change (at version [9fa2745](https://github.com/openjdk/jdk/commit/9fa2745960aea0bc45642081bac89fb5ef65809e)) is now ready to be sponsored by a Committer.

@tprinzing I don't mind sponsoring but I think it would help if you could sync up the branch and provide a summary on the testing was done.  The jdk_net and jdk_nio test groups are in tier2. The jdk_jfr test group is in tier3.

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1725248917

From duke at openjdk.org  Tue Sep 19 13:02:41 2023
From: duke at openjdk.org (Paul Wagland)
Date: Tue, 19 Sep 2023 13:02:41 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
 <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
Message-ID: <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>

On Tue, 19 Sep 2023 10:11:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> As regards Files.copy(InputStream, Path). It uses the input stream's transferTo method to transfer the bytes to the target file. It could be changed to write in chunks or the input streams that have all bytes in the heap could write in chunks. One or both is okay and doesn't have compatibility concerns.

Thanks for this answer. The challenge is that we are very dependent on the specific implementation of the input streams `transferTo` method. Specifically, the default implementation is perfectly fine, the one in (the old) BAIS caused us issues.

If I understand correctly though, after this PR you can just wrap _any_ InputStream into a BIS, and it would be safe, right? Maybe this is something that could be put into `Files.copy`? Then `Files.copy` would always work, and you aren't changing the short read/write characteristics?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1725466941

From pminborg at openjdk.org  Tue Sep 19 13:13:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Sep 2023 13:13:51 GMT
Subject: Integrated: 8316337: (bf) Concurrency issue in
 DirectByteBuffer.Deallocator
In-Reply-To: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
References: <skQdzrB7P7epjt6pdFpLR4ELG4Pp9WX9InZCSZh62OI=.4ea65d07-500e-4be6-88ed-0f845b00662d@github.com>
Message-ID: <zC6sy07HsknqsDgcmlMgfxLekujfEQLcEpDl__9cFcE=.3b4d7c37-a937-4f32-b8a3-c2716d4614fb@github.com>

On Mon, 18 Sep 2023 11:00:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability.

This pull request has now been integrated.

Changeset: cf74b8c2
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf74b8c2a32f33019a13ce80b6667da502cc6722
Stats:     53 lines in 3 files changed: 5 ins; 19 del; 29 mod

8316337: (bf) Concurrency issue in DirectByteBuffer.Deallocator

Reviewed-by: alanb, liach

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

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

From sgehwolf at openjdk.org  Tue Sep 19 13:59:17 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Sep 2023 13:59:17 GMT
Subject: RFR: 8316304: (fs) Add support for BasicFileAttributes.creationTime()
 for Linux
Message-ID: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>

Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.

Testing:
- [x] GHA (MacOS X failure seems unrelated)
- [x] `java.nio` tests.
- [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.

Thoughts?

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

Commit messages:
 - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

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

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

From alanb at openjdk.org  Tue Sep 19 14:02:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 14:02:43 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
 <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
 <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
Message-ID: <Xr6xfszukDMta4w7qEw6z0yV6XM11z7xT5FLp9XJLtA=.2bdb6be2-cba5-4a5f-97c7-b32a0cbc8a19@github.com>

On Tue, 19 Sep 2023 12:59:37 GMT, Paul Wagland <duke at openjdk.org> wrote:

> Thanks for this answer. The challenge is that we are very dependent on the specific implementation of the input streams `transferTo` method. Specifically, the default implementation is perfectly fine, the one in (the old) BAIS caused us issues.

The BAIS.transferTo implementation was a bit naive so it's useful to re-visit this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1725646174

From alanb at openjdk.org  Tue Sep 19 14:20:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 14:20:41 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <1O76xGJyjkAuOnQwWdyNKFN655DQdj3QABWOlCuoMHg=.c359453c-befc-49bd-ad3c-5adc7e620c06@github.com>

On Mon, 18 Sep 2023 17:05:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Is statx a complete superset of stat? If so, then the prototype should use it instead of stat, not in addition, meaning there should be one syscall rather than two.

If this goes ahead then I think should look at what it would take to move it src/java.base/linux, meaning the LinuxFileSystemProvider.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1725699261

From sgehwolf at openjdk.org  Tue Sep 19 14:48:39 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Sep 2023 14:48:39 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <1O76xGJyjkAuOnQwWdyNKFN655DQdj3QABWOlCuoMHg=.c359453c-befc-49bd-ad3c-5adc7e620c06@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <1O76xGJyjkAuOnQwWdyNKFN655DQdj3QABWOlCuoMHg=.c359453c-befc-49bd-ad3c-5adc7e620c06@github.com>
Message-ID: <JVZo6nSApvgA_brpxUXFB2Ocw-FVB8Np-FFH3IiuFyo=.e28ca4db-c3ba-4641-9b28-e3c1a1372eb6@github.com>

On Tue, 19 Sep 2023 14:17:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is statx a complete superset of stat? If so, then the prototype should use it instead of stat, not in addition, meaning there should be one syscall rather than two.

The reason why I've chosen this one so far is two fold: a) What to do if `statx` is not available? (`glibc < 2.28` and/or `kernel < 4.11`) b) it seems much less risky that way, as we are only changing creationTime reporting. Everything else remains unchanged. Thus, a better fit for backports. a) seems a blocker for older systems, so we would need two separate implementations anyway?

> If this goes ahead then I think should look at what it would take to move it src/java.base/linux, meaning the LinuxFileSystemProvider.

Incidentally, that's what my initial version was using and I've reconsidered going with this one instead since the complexity seemed not worth it. It would need to delegate to `UnixFileAttributes` anyway for older systems and the gist of the patch would be the native parts.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1725790579

From alanb at openjdk.org  Tue Sep 19 15:03:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Sep 2023 15:03:42 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <JVZo6nSApvgA_brpxUXFB2Ocw-FVB8Np-FFH3IiuFyo=.e28ca4db-c3ba-4641-9b28-e3c1a1372eb6@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <1O76xGJyjkAuOnQwWdyNKFN655DQdj3QABWOlCuoMHg=.c359453c-befc-49bd-ad3c-5adc7e620c06@github.com>
 <JVZo6nSApvgA_brpxUXFB2Ocw-FVB8Np-FFH3IiuFyo=.e28ca4db-c3ba-4641-9b28-e3c1a1372eb6@github.com>
Message-ID: <wRX8ddSdByPJ075R_Ea1pIpJDJN-ozYYKqWFR7HwKOU=.03fd5676-435a-4d72-ae59-72d6b49d2fba@github.com>

On Tue, 19 Sep 2023 14:45:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The reason why I've chosen this one so far is two fold: a) What to do if `statx` is not available? (`glibc < 2.28` and/or `kernel < 4.11`) b) it seems much less risky that way, as we are only changing creationTime reporting. Everything else remains unchanged. Thus, a better fit for backports. a) seems a blocker for older systems, so we would need two separate implementations anyway?

The code to use both will be there but when you invoke a method to get the file attributes in bulk then it should get a consistent view with one syscall.  Backports are not a concern here.

> Incidentally, that's what my initial version was using and I've reconsidered going with this one instead since the complexity seemed not worth it. It would need to delegate to `UnixFileAttributes` anyway for older systems and the gist of the patch would be the native parts.

I think this should be explored, maybe along the lines of BsdFileSystemProvider override getFileAttributeView so that it has a more specific implementation of each of the attribute views.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1725819037

From dfuchs at openjdk.org  Tue Sep 19 15:18:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Sep 2023 15:18:44 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v5]
In-Reply-To: <XQx22AT3AFHjoa-7vY9zjqpgU5mPtFYfu0WANDvW-ng=.2737cfa2-8fbb-4594-a3d5-b4e1e014c383@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <XQx22AT3AFHjoa-7vY9zjqpgU5mPtFYfu0WANDvW-ng=.2737cfa2-8fbb-4594-a3d5-b4e1e014c383@github.com>
Message-ID: <FkhlWdCx1iG0d31Ha2iEfVFU_i5YIabH_KaATXBjWRQ=.8b65a3b2-4c49-4391-9aaa-bb124b00c08a@github.com>

On Thu, 7 Sep 2023 21:50:17 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More changes from review:
>   
>   I didn't like the name of the helper method 'checkForCommit' because it
>   doesn't indicate that it might commit the event.  I also don't like
>   'commitEvent' because it might not.  Since JFR events are sort of like a
>   queue I went with a name from collections and called it 'offer' so using
>   it is something like 'SocketReadEvent.offer(...)' which seems like it
>   gets the idea across better.  Also improved the javadoc for it.
>   
>   Removed the comments about being instrumented by JFR in
>   Socket.SocketInputStream and Socket.SocketOutputStream.
>   
>   I went ahead and moved the event commiting out of the finally block so
>   that we don't emit events when the read/write did not actually happen.
>   The bugid JDK-8310979 will be used to determine if more should be done
>   in this area.
>   
>   The implRead and implWrite were moved up with the other support methods
>   for read/write.

LGTM. Are there existing that will help verify that the read events and write events are still emitted as expected? If not shouldn't we write some?

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

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1633551891

From dfuchs at openjdk.org  Tue Sep 19 15:18:45 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Sep 2023 15:18:45 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <fbRpcgvGTiIi3_dpDxEJQhdlfP8Dz87QMpG3cchORJA=.9d6188c0-b364-403c-aad0-2488ff167764@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
 <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
 <dHY_YlyH_mN3TaYO-ZzBtyqTEAs7vSlc8_L8_MsGXgU=.e071811b-a84d-4c31-89b6-3cadc4048ef3@github.com>
 <fbRpcgvGTiIi3_dpDxEJQhdlfP8Dz87QMpG3cchORJA=.9d6188c0-b364-403c-aad0-2488ff167764@github.com>
Message-ID: <uo7m6eqX-viQ_zPzIMZbTZGoG3bI8SrMSXxS0v2Rq4Y=.99a49c30-f13e-4f95-967b-b340c54ef49b@github.com>

On Thu, 7 Sep 2023 21:54:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> No. I think it's a relic from the distant past though. I think the timeout field should be removed. It's not used on SocketChannel at all, and it doesn't seem useful on Socket.

Should we log an RFE to that effect?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1330294609

From tprinzing at openjdk.org  Tue Sep 19 15:35:11 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 19 Sep 2023 15:35:11 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8308995
 - More changes from review:
   
   I didn't like the name of the helper method 'checkForCommit' because it
   doesn't indicate that it might commit the event.  I also don't like
   'commitEvent' because it might not.  Since JFR events are sort of like a
   queue I went with a name from collections and called it 'offer' so using
   it is something like 'SocketReadEvent.offer(...)' which seems like it
   gets the idea across better.  Also improved the javadoc for it.
   
   Removed the comments about being instrumented by JFR in
   Socket.SocketInputStream and Socket.SocketOutputStream.
   
   I went ahead and moved the event commiting out of the finally block so
   that we don't emit events when the read/write did not actually happen.
   The bugid JDK-8310979 will be used to determine if more should be done
   in this area.
   
   The implRead and implWrite were moved up with the other support methods
   for read/write.
 - less exception filtering when fetching socket read timeout
 - remove unused SOCKET_READ and SOCKET_WRITE configurations.
 - Merge branch 'master' into JDK-8308995
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
 - Avoid exceptions getting address/timeout for jfr event. Remove unused
   EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
   whitespace.
 - some changes from review.
   
   read0() to implRead()
   write0() to implWrite()
   trailing whitespace
 - fix copyright date
 - Added micro benchmark to measure socket event overhead.
 - Some changes from review.
   
   Append a 0 to method names being wrapped.  Use getHostString to avoid
   a reverse lookup when fetching the hostname of the remote address.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

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

Changes: https://git.openjdk.org/jdk/pull/14342/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=05
  Stats: 906 lines in 13 files changed: 519 ins; 379 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

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

From duke at openjdk.org  Tue Sep 19 16:34:44 2023
From: duke at openjdk.org (Paul Wagland)
Date: Tue, 19 Sep 2023 16:34:44 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
 <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
 <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
Message-ID: <vGFAvwe86HhqjIM-5xQk5iEShwkTOM6bPZmEEn0kulQ=.b8e6d855-4e43-48ec-8624-1665c46df6c1@github.com>

On Tue, 19 Sep 2023 12:59:37 GMT, Paul Wagland <duke at openjdk.org> wrote:

> If I understand correctly though, after this PR you can just wrap _any_ InputStream into a BIS, and it would be safe, right? Maybe this is something that could be put into `Files.copy`? Then `Files.copy` would always work, and you aren't changing the short read/write characteristics?

Would it make sense to also do this, to ensure that `Files.copy` doesn't fail, regardless of what the input InputStream does?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1726044547

From bpb at openjdk.org  Tue Sep 19 17:02:42 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 17:02:42 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <vGFAvwe86HhqjIM-5xQk5iEShwkTOM6bPZmEEn0kulQ=.b8e6d855-4e43-48ec-8624-1665c46df6c1@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
 <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
 <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
 <vGFAvwe86HhqjIM-5xQk5iEShwkTOM6bPZmEEn0kulQ=.b8e6d855-4e43-48ec-8624-1665c46df6c1@github.com>
Message-ID: <OYzEwDrIpeGt_tkDukWeEnhrj7KcWKSzdnmkcBS7-2c=.0167b6b7-2b16-4cb2-aa4c-7162df698a9c@github.com>

On Tue, 19 Sep 2023 16:31:48 GMT, Paul Wagland <duke at openjdk.org> wrote:

> Would it make sense to also do this, to ensure that `Files.copy` doesn't fail, regardless of what the input InputStream does?

It would make sense to clamp the uses of `transferTo` in `Files.copy` to a maximum chunk size, but I don't think wrapping in a `ByteArrayInputstream` is the way to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1726092353

From bpb at openjdk.org  Tue Sep 19 17:40:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 17:40:43 GMT
Subject: RFR: 8316156: (ch)
 Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct
 memory [v5]
In-Reply-To: <OYzEwDrIpeGt_tkDukWeEnhrj7KcWKSzdnmkcBS7-2c=.0167b6b7-2b16-4cb2-aa4c-7162df698a9c@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <oLRhbU8mMltnhHhRm-y4J_UqTUExKoas5dY9Zx8gl20=.9b84ccf6-269f-4ab3-ad02-8b163cbc672e@github.com>
 <I3dtlG37YIOmWBMpI22E2CJs-IT6-xazEuHN2cGQQ3A=.2bff34ea-e5e2-4f30-b3b4-45b7cf1ac949@github.com>
 <tPig78U4AL6A5TQ8ZLAvl_qUa5Tx3DGEcKjfMzoa4Yw=.029ba6c1-8deb-4327-b49f-5b0ff2bff1c2@github.com>
 <F1UgRJqwN5q37gwOykOK1UN4AYIc9ed6dFcrKXpFEcA=.1e22ddf2-89ef-4fc5-bd92-e9cf348448e1@github.com>
 <vGFAvwe86HhqjIM-5xQk5iEShwkTOM6bPZmEEn0kulQ=.b8e6d855-4e43-48ec-8624-1665c46df6c1@github.com>
 <OYzEwDrIpeGt_tkDukWeEnhrj7KcWKSzdnmkcBS7-2c=.0167b6b7-2b16-4cb2-aa4c-7162df698a9c@github.com>
Message-ID: <pygar19QSmDPFNygUVX-bfnwx6P9jqQIb5ogpyDSaAE=.808fd035-a4c7-4bb0-a601-511920a6c20d@github.com>

On Tue, 19 Sep 2023 16:59:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It would make sense to clamp the uses of `transferTo` in `Files.copy` to a maximum chunk size [...]

The problem with chunking `InputStream.transferTo` here is that it _might_ seriously compromise performance when the IS is backed by a FileChannel.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1726203513

From jlu at openjdk.org  Tue Sep 19 18:21:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Sep 2023 18:21:41 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
In-Reply-To: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
References: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
Message-ID: <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>

On Tue, 19 Sep 2023 01:01:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

Actually tests 138 charsets now, looks good

test/jdk/sun/nio/cs/TestCharsetMapping.java line 574:

> 572:             "/../../../../../make/data/charsetmapping");
> 573:         if (!Files.exists(dir)) {
> 574:             throw new Exception("charsetmapping directory cannot be located.");

Might be helpful to provide directory location in exception message

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15807#pullrequestreview-1633923524
PR Review Comment: https://git.openjdk.org/jdk/pull/15807#discussion_r1330529497

From naoto at openjdk.org  Tue Sep 19 20:03:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 20:03:51 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
References: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
Message-ID: <lX88CDGwV3iZkkp8DPWkfLSNRhcPzAAXqcCYixcvj9Y=.1e8735a6-eeb1-492a-af0d-304c14ad1e35@github.com>

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Included the failed directory location in the exception message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15807/files
  - new: https://git.openjdk.org/jdk/pull/15807/files/e2731ff8..6d28a5ae

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

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

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

From naoto at openjdk.org  Tue Sep 19 20:03:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Sep 2023 20:03:54 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>
References: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
 <0alx86jS3MrF7a0gEtUN7Wgm8J70tfBflpSDSBDlvTc=.4875ab96-5168-48c3-8c53-7cca1f0375c8@github.com>
Message-ID: <CGpRKG4NiH_k9k9NRhXPgfUnpxiPjMTrR7viCjvpjSc=.010a686c-409b-42a0-9363-7fbaf58cd66a@github.com>

On Tue, 19 Sep 2023 18:15:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Included the failed directory location in the exception message
>
> test/jdk/sun/nio/cs/TestCharsetMapping.java line 574:
> 
>> 572:             "/../../../../../make/data/charsetmapping");
>> 573:         if (!Files.exists(dir)) {
>> 574:             throw new Exception("charsetmapping directory cannot be located.");
> 
> Might be helpful to provide directory location in exception message

Good point. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15807#discussion_r1330639943

From bpb at openjdk.org  Tue Sep 19 20:03:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 20:03:57 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>

> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8316156: Revert BufferedInputStream changes; update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15733/files
  - new: https://git.openjdk.org/jdk/pull/15733/files/7ee65b90..11cf9ffb

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

  Stats: 62 lines in 2 files changed: 8 ins; 48 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15733/head:pull/15733

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

From bpb at openjdk.org  Tue Sep 19 20:08:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Sep 2023 20:08:41 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
Message-ID: <QI4_L6a6rz1i5aCiRYhNmgiX64vsnJ6qxdAeihHjRJI=.9f8f7758-19f7-45f7-9c9b-35ab899ac793@github.com>

On Tue, 19 Sep 2023 20:03:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert BufferedInputStream changes; update test

This PR is now limited to `ByteArrayInputStream`. The use of `InputStream.transferTo` in `Files.copy(InputStream,Path)` and `Files.copy(Path,Outputstream)` can be investigated in the context of a different issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1726396665

From tprinzing at openjdk.org  Tue Sep 19 20:54:48 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 19 Sep 2023 20:54:48 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
Message-ID: <McyLwie1FyML-TWkGr9fbfozNJ7yABDFbhdx6l6PXu0=.c3a63719-54fe-4e17-82e8-75238651ef9c@github.com>

On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into JDK-8308995
>  - More changes from review:
>    
>    I didn't like the name of the helper method 'checkForCommit' because it
>    doesn't indicate that it might commit the event.  I also don't like
>    'commitEvent' because it might not.  Since JFR events are sort of like a
>    queue I went with a name from collections and called it 'offer' so using
>    it is something like 'SocketReadEvent.offer(...)' which seems like it
>    gets the idea across better.  Also improved the javadoc for it.
>    
>    Removed the comments about being instrumented by JFR in
>    Socket.SocketInputStream and Socket.SocketOutputStream.
>    
>    I went ahead and moved the event commiting out of the finally block so
>    that we don't emit events when the read/write did not actually happen.
>    The bugid JDK-8310979 will be used to determine if more should be done
>    in this area.
>    
>    The implRead and implWrite were moved up with the other support methods
>    for read/write.
>  - less exception filtering when fetching socket read timeout
>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>  - Merge branch 'master' into JDK-8308995
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>    whitespace.
>  - some changes from review.
>    
>    read0() to implRead()
>    write0() to implWrite()
>    trailing whitespace
>  - fix copyright date
>  - Added micro benchmark to measure socket event overhead.
>  - Some changes from review.
>    
>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>    a reverse lookup when fetching the hostname of the remote address.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

I sync'd master and updated the bug report with the successful test results.

Created [JDK-8316558] to track potential timeout field removal.  

The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1726449349

From alanb at openjdk.org  Wed Sep 20 07:07:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 07:07:43 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>

On Mon, 18 Sep 2023 17:05:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

One other thing to try is to rename prepAttributes to something like copyStatAttributes and add a copyStatXAttributes that copies the fields from the statx structure. That on its own go with call stat or statx, never both.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1727093997

From alanb at openjdk.org  Wed Sep 20 07:12:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 07:12:45 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
Message-ID: <eZYr525EC8HlWEblUN2xLsuwAFGBy2YaC57MuCdd9rw=.1ef3d276-4d97-4d63-be48-7935ed3da9c2@github.com>

On Tue, 19 Sep 2023 20:03:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert BufferedInputStream changes; update test

The change to BAIS.tranfserTo write at most 128k at a time looks okay. The test looks okay and I assume you've checked the test is stable with 5Mb.

The PR description is a bit outdated now, I assume you can edit that so it aligns with what this change is about.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15733#pullrequestreview-1634825723

From duke at openjdk.org  Wed Sep 20 07:13:17 2023
From: duke at openjdk.org (Deepa Kumari)
Date: Wed, 20 Sep 2023 07:13:17 GMT
Subject: RFR: 8308807: MulticastSocket cannot join IPv4 multicast group
 when IPv6 is enabled (aix) [v2]
In-Reply-To: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
Message-ID: <ASKB7sluyu_6CL3hC3wxTVOTg7Dwvouik3U5KEiBDIs=.e98c164f-8137-4d89-890f-f37d73103b0d@github.com>

> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
> 
> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
> 
> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
> 
> 
> 
> 
> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)

Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Added Space
 - 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup

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

Changes: https://git.openjdk.org/jdk/pull/14142/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14142&range=01
  Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14142/head:pull/14142

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

From alanb at openjdk.org  Wed Sep 20 07:19:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 07:19:50 GMT
Subject: RFR: 8308807: MulticastSocket cannot join IPv4 multicast group
 when IPv6 is enabled (aix) [v2]
In-Reply-To: <ASKB7sluyu_6CL3hC3wxTVOTg7Dwvouik3U5KEiBDIs=.e98c164f-8137-4d89-890f-f37d73103b0d@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <ASKB7sluyu_6CL3hC3wxTVOTg7Dwvouik3U5KEiBDIs=.e98c164f-8137-4d89-890f-f37d73103b0d@github.com>
Message-ID: <iKfW-HfvZUbiRxdRBdQXBcIbxuzIS0DvZS8px36Ibe8=.63cfd7e1-2596-4766-9948-c6a451faa173@github.com>

On Wed, 20 Sep 2023 07:13:17 GMT, Deepa Kumari <duke at openjdk.org> wrote:

>> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
>> 
>> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
>> 
>> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
>> 
>> 
>> 
>> 
>> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)
>
> Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Added Space
>  - 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup

I see this PR has been re-based but it has the same changes as before. This PR lacks an authoritative statement on what AIX supports and doesn't supports, I don't think it's possible to make any progress without that.

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

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1727108792

From sgehwolf at openjdk.org  Wed Sep 20 10:15:51 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Sep 2023 10:15:51 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
Message-ID: <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>

On Wed, 20 Sep 2023 07:04:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One other thing to try is to rename prepAttributes to something like copyStatAttributes and add a copyStatXAttributes that copies the fields from the statx structure. That goes with calling stat or statx, never both.

OK. Just to clarify: if `statx` is available it should use it and retrieve all needed attributes from the statx call (if all attributes can be retrieved that way). Otherwise use `stat64/lstat` as before (with birth time missing).

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1727409460

From dfuchs at openjdk.org  Wed Sep 20 11:26:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Sep 2023 11:26:46 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <McyLwie1FyML-TWkGr9fbfozNJ7yABDFbhdx6l6PXu0=.c3a63719-54fe-4e17-82e8-75238651ef9c@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
 <McyLwie1FyML-TWkGr9fbfozNJ7yABDFbhdx6l6PXu0=.c3a63719-54fe-4e17-82e8-75238651ef9c@github.com>
Message-ID: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>

On Tue, 19 Sep 2023 20:51:41 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The existing JFR tests TestSocketChannelEvents and TestSocketEvents in jdk.jfr.event.io verify the events are still emitted as expected.

Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727528861

From alanb at openjdk.org  Wed Sep 20 11:26:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 11:26:47 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
 <McyLwie1FyML-TWkGr9fbfozNJ7yABDFbhdx6l6PXu0=.c3a63719-54fe-4e17-82e8-75238651ef9c@github.com>
 <_SswosDeHNVdHm-0KVa9Pjfi65wnESObTy9RI3mVMjs=.7c401051-50b2-4777-a15d-ba2bf27eb38a@github.com>
Message-ID: <8dq0EZ2nZuSs-fQhlpSODsL6J_5ueLLBYK4tQy3EHTo=.bb1aa2d6-a760-4857-9671-b530d0aa4883@github.com>

On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests?

I don't think so as these tests are just used to check that changes haven't broken anything.

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1727532006

From dfuchs at openjdk.org  Wed Sep 20 11:35:48 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Sep 2023 11:35:48 GMT
Subject: RFR: 8308807: MulticastSocket cannot join IPv4 multicast group
 when IPv6 is enabled (aix) [v2]
In-Reply-To: <ASKB7sluyu_6CL3hC3wxTVOTg7Dwvouik3U5KEiBDIs=.e98c164f-8137-4d89-890f-f37d73103b0d@github.com>
References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com>
 <ASKB7sluyu_6CL3hC3wxTVOTg7Dwvouik3U5KEiBDIs=.e98c164f-8137-4d89-890f-f37d73103b0d@github.com>
Message-ID: <11YSzXn-BVAWz0K2FoQljyi5qxSzWbZOs7kj0UP93NY=.d5d97274-5ee9-4115-a017-757f002a1b9d@github.com>

On Wed, 20 Sep 2023 07:13:17 GMT, Deepa Kumari <duke at openjdk.org> wrote:

>> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. 
>> 
>> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group.
>> 
>> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. 
>> 
>> 
>> 
>> 
>> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807)
>
> Deepa Kumari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Added Space
>  - 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup

I concur with Alan that the changes proposed here are not appropriate for DatagramSocket/MulticastSocket.

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

PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1727545016

From alanb at openjdk.org  Wed Sep 20 12:22:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Sep 2023 12:22:41 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
 <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>
Message-ID: <gnHprO7sMCVHuRm1Cg-UUSqB3OhbJ_XHx9aPZgwGzOI=.6935a8af-a4a0-4611-9129-038e01a1ce2e@github.com>

On Wed, 20 Sep 2023 10:13:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> OK. Just to clarify: if `statx` is available it should use it and retrieve all needed attributes from the statx call (if all attributes can be retrieved that way). Otherwise use `stat64/lstat` as before (with birth time missing).

Yes, I think we should think of statx as an extended stat.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1727612597

From tprinzing at openjdk.org  Wed Sep 20 12:37:02 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 20 Sep 2023 12:37:02 GMT
Subject: Integrated: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <iJtnIRw00d0PrEm2v53SPRrKtMYQ1a5RxBgm4xr5rDk=.a55e74bb-aad7-4590-aa78-6c9975950cee@github.com>

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

This pull request has now been integrated.

Changeset: b275bdd9
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b275bdd9b55b567cfe60c389d5ef8b70615928f4
Stats:     906 lines in 13 files changed: 519 ins; 379 del; 8 mod

8308995: Update Network IO JFR events to be static mirror events

Reviewed-by: egahlin, alanb

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

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

From bpb at openjdk.org  Wed Sep 20 15:18:41 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 15:18:41 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <eZYr525EC8HlWEblUN2xLsuwAFGBy2YaC57MuCdd9rw=.1ef3d276-4d97-4d63-be48-7935ed3da9c2@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
 <eZYr525EC8HlWEblUN2xLsuwAFGBy2YaC57MuCdd9rw=.1ef3d276-4d97-4d63-be48-7935ed3da9c2@github.com>
Message-ID: <_GFHk4IquIpvYunGhJBuiYYBX2GxIhU9H55t11wGFqg=.74eeaee1-185f-4339-9bc9-43c400a36ffc@github.com>

On Wed, 20 Sep 2023 07:09:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test looks okay and I assume you've checked the test is stable with 5Mb.

I have not seen any problems but am running more tests before integrating.

> The PR description is a bit outdated now, I assume you can edit that so it aligns with what this change is about.

I will update it.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1727933096

From andrew at openjdk.org  Wed Sep 20 17:57:42 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 20 Sep 2023 17:57:42 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <en7Oh7OgGJ50LWatcl08a6jH_H1TSvlbElSkit9nrE4=.0262c51a-ffaa-4e13-b7ad-b74584fd86cc@github.com>

On Mon, 18 Sep 2023 17:05:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Using either `statx` or `stat64` makes sense to me. I can see why you might want the safety of having the other attributes available on a system which thinks it has `statx`, but fails for some reason, but that also makes the situation hard to debug. Do you have no creation time because `statx` is not supported or because it failed? Also, in the proposed patch, the failing `statx` would fail the entire function anyway, so you wouldn't get the other attributes from `stat64` as far as I can see.

Looking at `statx`, the fields pretty much map onto the `stat64` ones with `st_` replaced with `stx_`. The exceptions are `rdev` and `dev` which `statx` provides split into major and minor. The `makedev` function can be used to convert this pair into a `dev_t`. 
We also seem to be missing use of nanoseconds for birthtime. Was this absent on Mac OS? It would be good to make this consistent with a/m/ctime and provide greater accuracy.

Using one or the other seems like it might also reduce some of the duplication here. It is a bit odd to have all attributes initialised in `prepAttributes` but then another adjusted outside that in three different places. Maybe we could instead just wrap `prepAttributes` in a wrapper function which calls `copyStatAttributes` or `copyStatXAttributes` as appropriate?  It seems feasible you could even copy the `statx` fields into a `stat64` buffer and re-use `prepAttributes` as is.

I don't see how moving this to a Linux-specific class would work. Would that not mean a lot of duplication with the `stat64` handling, not to mention some Linux systems may still need to use `stat64`? It's not like there isn't a whole bunch of platform-specific code in the file already and the separate class seems more appropriate for cases where the feature is only available on Linux, not where the feature can be handled slightly differently on some Linux systems.

Could `STATX_POSSIBLY_AVAILABLE` not just be replaced with `defined(__linux__)` for clarity? Or maybe that is part of the intention that `statx` may potentially be available on other platforms in future?

I don't really get the point about backports. According to [the build platform Wiki page](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms), Oracle still build JDK 20 against a OEL 6 or 7 buildroot, which means a `glibc` that doesn't support `statx`. I expect most builds of 22 will be in an environment without `statx`, but plenty will run in one where it is.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1728194468

From bpb at openjdk.org  Wed Sep 20 18:34:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 18:34:44 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <_GFHk4IquIpvYunGhJBuiYYBX2GxIhU9H55t11wGFqg=.74eeaee1-185f-4339-9bc9-43c400a36ffc@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
 <eZYr525EC8HlWEblUN2xLsuwAFGBy2YaC57MuCdd9rw=.1ef3d276-4d97-4d63-be48-7935ed3da9c2@github.com>
 <_GFHk4IquIpvYunGhJBuiYYBX2GxIhU9H55t11wGFqg=.74eeaee1-185f-4339-9bc9-43c400a36ffc@github.com>
Message-ID: <GgQJguSn8JlDaI5MbWFy5IPwjxnWzXEZSIz-brnDJv4=.da6da98a-321e-4b4a-af57-cfb13ae6a890@github.com>

On Wed, 20 Sep 2023 15:15:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I have not seen any problems but am running more tests before integrating.

50 repeats of the test on the usual four platforms succeeded.

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1728240713

From bpb at openjdk.org  Wed Sep 20 20:45:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Sep 2023 20:45:53 GMT
Subject: Integrated: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow
In-Reply-To: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
Message-ID: <2IX679GYzEqfTtIwMRNCrEJr1ewKFJo1EYtpPkynUzI=.5b0d34bd-8a46-4331-a46b-2f2f605ddc7a@github.com>

On Thu, 14 Sep 2023 03:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `ByteArrayInputStream.transferTo` invoked with an `OutputStream` parameter which delegates to a `FileChannel` throws an `OutOfMemoryError` if the length of the `byte[]` wrapped by the `ByteArrayInputStream` exceeds `MaxDirectMemorySize`. This is because `FileChannel.write` uses `IOUtil.write` which creates a temporary direct buffer for writing. If the `byte[]` length is larger than `MaxDirectMemorySize`, then the temporary direct buffer allocation fails with an `OutOfMemoryError`.

This pull request has now been integrated.

Changeset: 5cacf212
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cacf212f066f5694d01f0891adfbe8b38660175
Stats:     83 lines in 2 files changed: 81 ins; 0 del; 2 mod

8316156: ByteArrayInputStream.transferTo causes MaxDirectMemorySize overflow

Reviewed-by: alanb

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

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

From pminborg at openjdk.org  Thu Sep 21 10:52:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 10:52:04 GMT
Subject: RFR: 8316660: Use a MemorSegment for file mapping in
 FileChannelLinesSpliterator
Message-ID: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>

This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in `FileChannelLinesSpliterator`.

The old solution deterministically unmapped the ByteBuffer if closed. If not closed, the ByteBuffer would be GC:ed.

This proposal mimics the old behavior but may hold the mapped memory region slightly longer.

Tested and passed tier1, tier2, tier3

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

Commit messages:
 - Fix typo
 - Rename variables
 - Add test for parallel use of FileChannelLinesSpliterator
 - Use CleanerFactory.cleaner()
 - Update javadoc to reflect the use of memory segment
 - Refactor cleanup
 - Merge branch 'master' into pz-fclinespliterator
 - Add a Cleaner
 - Rename method again
 - Rename method
 - ... and 1 more: https://git.openjdk.org/jdk/compare/fab372d3...9b23ecbe

Changes: https://git.openjdk.org/jdk/pull/15814/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316660
  Stats: 222 lines in 3 files changed: 165 ins; 23 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15814/head:pull/15814

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

From liach at openjdk.org  Thu Sep 21 10:52:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Sep 2023 10:52:04 GMT
Subject: RFR: 8316660: Use a MemorSegment for file mapping in
 FileChannelLinesSpliterator
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <OVqLO6BC74kGwAAKTYqWpM4Ag4BQDVE2ylLp4dPwgZ8=.27ee0ed5-9881-4a26-8c03-76b986ba3732@github.com>

On Tue, 19 Sep 2023 08:52:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in `FileChannelLinesSpliterator`.
> 
> The old solution deterministically unmapped the ByteBuffer if closed. If not closed, the ByteBuffer would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java line 199:

> 197:     }
> 198: 
> 199:     private MemorySegment getMappedByteBuffer() {

This method's name should be updated now that the return type has changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15814#discussion_r1329839027

From alanb at openjdk.org  Thu Sep 21 10:53:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Sep 2023 10:53:41 GMT
Subject: RFR: 8316660: Use a MemorSegment for file mapping in
 FileChannelLinesSpliterator
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <96TbhNo-DijRLkSYj29H0Jpv6Ewz5dOs9mqU66iEQf0=.27fadb41-f357-4df9-9670-2fe09b9405fd@github.com>

On Tue, 19 Sep 2023 08:52:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in `FileChannelLinesSpliterator`.
> 
> The old solution deterministically unmapped the ByteBuffer if closed. If not closed, the ByteBuffer would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

test/jdk/java/nio/file/FileChannelLinesSpliterator/Parallel.java line 45:

> 43: import static org.junit.jupiter.api.Assertions.*;
> 44: 
> 45: public class Parallel {

This test should needs to move to test/jdk/java/nio/file/Files and be named something like LinesParallel. The description can also say that it's a test for Files.lines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15814#discussion_r1332866695

From alanb at openjdk.org  Thu Sep 21 11:06:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Sep 2023 11:06:40 GMT
Subject: RFR: 8316660: Use a MemorSegment for file mapping in
 FileChannelLinesSpliterator
In-Reply-To: <96TbhNo-DijRLkSYj29H0Jpv6Ewz5dOs9mqU66iEQf0=.27fadb41-f357-4df9-9670-2fe09b9405fd@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
 <96TbhNo-DijRLkSYj29H0Jpv6Ewz5dOs9mqU66iEQf0=.27fadb41-f357-4df9-9670-2fe09b9405fd@github.com>
Message-ID: <KV7M3XiwR7eMcnceSanZZ5QjBVC9n9ya6I16uzmqxfc=.706d2b8e-ae8e-4f89-9adc-77956a296d0b@github.com>

On Thu, 21 Sep 2023 10:50:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in `FileChannelLinesSpliterator`.
>> 
>> The old solution deterministically unmapped the ByteBuffer if closed. If not closed, the ByteBuffer would be GC:ed.
>> 
>> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
>> 
>> Tested and passed tier1, tier2, tier3
>
> test/jdk/java/nio/file/FileChannelLinesSpliterator/Parallel.java line 45:
> 
>> 43: import static org.junit.jupiter.api.Assertions.*;
>> 44: 
>> 45: public class Parallel {
> 
> This test should needs to move to test/jdk/java/nio/file/Files and be named something like LinesParallel. The description can also say that it's a test for Files.lines.

I also changed the JBS issue to make it clear that this is about the Files.lines implementation, do you mind adjusting the PR to align with that as "FileChannelLinesSplitator" is an internal class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15814#discussion_r1332880813

From pminborg at openjdk.org  Thu Sep 21 11:52:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 11:52:27 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v2]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <1x3aPgjx3-0zEA6QzDY7CnCM2Gl14kfpW2c7tbg0qSM=.ee12fd38-8990-4fe8-bf9d-f48f33b157ff@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Move test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/9b23ecbe..e8ce5910

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

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

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

From pminborg at openjdk.org  Thu Sep 21 13:02:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 13:02:29 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v3]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <Kphe7buAwi4TYbtdpugMTfvhn5WxXMSpdLBziGSERRU=.f839d02a-a7e1-44de-ac82-3c26cc1c5b60@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use a shared state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/e8ce5910..2cbdf366

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

  Stats: 97 lines in 2 files changed: 44 ins; 34 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15814/head:pull/15814

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

From pminborg at openjdk.org  Thu Sep 21 13:45:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 13:45:49 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v4]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <24RL4pyp6CdXgjNZPXl7nOZr2UsidqMLOrcTVStkg2g=.e13489b8-66be-4a4c-a2b8-4467c6ae4284@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a reachability fence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/2cbdf366..8b64e5a7

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

  Stats: 62 lines in 1 file changed: 22 ins; 16 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15814/head:pull/15814

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

From pminborg at openjdk.org  Thu Sep 21 13:50:32 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 13:50:32 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v5]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <GizgtTNk20fnwLi28vx-zs5TExeSLh76b7SuYXEUOMk=.82ecd213-7b35-4245-98a5-6ded02a7ea25@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/8b64e5a7..c606d420

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

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

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

From bpb at openjdk.org  Thu Sep 21 15:48:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 15:48:44 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v5]
In-Reply-To: <GizgtTNk20fnwLi28vx-zs5TExeSLh76b7SuYXEUOMk=.82ecd213-7b35-4245-98a5-6ded02a7ea25@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
 <GizgtTNk20fnwLi28vx-zs5TExeSLh76b7SuYXEUOMk=.82ecd213-7b35-4245-98a5-6ded02a7ea25@github.com>
Message-ID: <Z5HcpqJwlACr8ka7JK4fWV4yCEXi3NFJx6rqnr7AeB8=.3836dfa9-cc3b-4f89-8cc3-442e3995bc9c@github.com>

On Thu, 21 Sep 2023 13:50:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
>> 
>> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
>> 
>> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
>> 
>> Tested and passed tier1, tier2, tier3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify constructor

src/java.base/share/classes/java/nio/file/FileChannelLinesSpliterator.java line 75:

> 73: 
> 74:     static final Set<Charset> SUPPORTED_CHARSETS = Set.of(
> 75:             UTF_8.INSTANCE,

Suggestion: change indentation of these three set elements back to what it was.

src/java.base/share/classes/java/nio/file/Files.java line 4138:

> 4136:             if (length > 0 && length <= Integer.MAX_VALUE) {
> 4137:                 FileChannelLinesSpliterator fcls =
> 4138:                     new FileChannelLinesSpliterator(fc, cs,(int) length);

Suggestion: `, (int) length` -> `, (int)length`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15814#discussion_r1333279733
PR Review Comment: https://git.openjdk.org/jdk/pull/15814#discussion_r1333277522

From pminborg at openjdk.org  Thu Sep 21 16:18:24 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 16:18:24 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v6]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <Yr-MWzqRhyW6XAlPgA0BYz4ZRfhP85jhfX78ojL4ToQ=.891f541f-2f02-42ec-865b-d7314a32258a@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing test on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/c606d420..ce40d46a

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

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

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

From pminborg at openjdk.org  Thu Sep 21 16:24:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Sep 2023 16:24:22 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v7]
In-Reply-To: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
Message-ID: <yp3NtupNrRoZvvhJYNnI-Lj8Y9u55sDgqINTIW-Egn8=.80767e78-2b8a-4d12-af34-7ff40320824c@github.com>

> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
> 
> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
> 
> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
> 
> Tested and passed tier1, tier2, tier3

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15814/files
  - new: https://git.openjdk.org/jdk/pull/15814/files/ce40d46a..2c4d8b8f

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

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

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

From sgehwolf at openjdk.org  Thu Sep 21 17:29:44 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Sep 2023 17:29:44 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v2]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <YIsEc_95Ku1GhonWFVtpBEfTjL5Q3-w_XgGXbp4gIvw=.8dba8dc5-6821-4b27-bcf5-00ec9536c345@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/7524a30d..3ead43a1

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

  Stats: 852 lines in 14 files changed: 649 ins; 168 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From sgehwolf at openjdk.org  Thu Sep 21 17:41:39 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Sep 2023 17:41:39 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <gnHprO7sMCVHuRm1Cg-UUSqB3OhbJ_XHx9aPZgwGzOI=.6935a8af-a4a0-4611-9129-038e01a1ce2e@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
 <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>
 <gnHprO7sMCVHuRm1Cg-UUSqB3OhbJ_XHx9aPZgwGzOI=.6935a8af-a4a0-4611-9129-038e01a1ce2e@github.com>
Message-ID: <arHnNCfEU4YSOfHj-iRN4ICxZ3kBUqBy69JXJUqcDFQ=.a056a4d4-4abf-4386-a3e1-8fc85b835597@github.com>

On Wed, 20 Sep 2023 12:19:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> One other thing to try is to rename prepAttributes to something like copyStatAttributes and add a copyStatXAttributes that copies the fields from the statx structure. That goes with calling stat or statx, never both.
>> 
>> OK. Just to clarify: if `statx` is available it should use it and retrieve all needed attributes from the statx call (if all attributes can be retrieved that way). Otherwise use `stat64/lstat` as before (with birth time missing).
>
>> OK. Just to clarify: if `statx` is available it should use it and retrieve all needed attributes from the statx call (if all attributes can be retrieved that way). Otherwise use `stat64/lstat` as before (with birth time missing).
> 
> Yes, I think we should think of statx as an extended stat.

@AlanBateman @gnu-andrew Thanks for your input! Here is an updated patch, now using LinuxFileSystemProvider and the logic to use `statx` is now in the linux specific directory trees. The fallback code is unchanged (using `UnixNativeDispatcher`). This version never uses both `stat64` and `statx`. It only uses `statx` if its available and uses the older `stat64` otherwise. 

On a Linux system that has `statx` (using `LastModified` from the bug):

# grep test.txt strace_out.log 
execve("./jdk-22.0.0+0/bin/java", ["./jdk-22.0.0+0/bin/java", "LastModified", "test.txt"], 0xffffe07f0b98 /* 42 vars */) = 0
[pid 17058] statx(AT_FDCWD, "test.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
# stat test.txt 
  File: test.txt
  Size: 0         	Blocks: 0          IO Block: 65536  regular empty file
Device: fd00h/64768d	Inode: 100734611   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-09-21 13:14:00.464356794 -0400
Modify: 2000-01-01 01:01:00.000000000 -0500
Change: 2023-09-21 13:17:13.835434277 -0400
 Birth: 2023-09-21 13:12:13.033760507 -0400


On a Linux system that doesn't have `statx`:

# grep 'stat' strace_out.log  | grep testme
[pid  8302] stat("testme.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
# stat testme.txt 
  File: ?testme.txt?
  Size: 0         	Blocks: 0          IO Block: 65536  regular empty file
Device: fd00h/64768d	Inode: 100822778   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-09-21 13:09:46.459640944 -0400
Modify: 2000-01-01 01:01:00.000000000 -0500
Change: 2023-09-21 13:16:08.142395814 -0400
 Birth: -

Please let me know what you think!

FWIW, I've compiled this fine on Alpine Linux, so there aren't any glibc guards anymore.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1730023723

From bpb at openjdk.org  Thu Sep 21 18:00:51 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Sep 2023 18:00:51 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v6]
In-Reply-To: <GktLFQdoXKSqjX57gf034-xUrP1w17qXxComET-TrlE=.94a7a2b5-5d85-4a0e-99ab-214e27cc019d@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <61iT0thXowe5njSVm05uP56WwXloJxcpXxfN4C0jxYY=.a03062e9-7417-4801-a74d-7781a3557253@github.com>
 <GktLFQdoXKSqjX57gf034-xUrP1w17qXxComET-TrlE=.94a7a2b5-5d85-4a0e-99ab-214e27cc019d@github.com>
Message-ID: <GxJ_m54VpDOsMCO_1ZOZanio_3jYmIsQtO2-9HtvBnQ=.bc8318c0-79a4-447e-91fd-e4f16311ad14@github.com>

On Sun, 17 Sep 2023 08:18:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8073061: Tweak CopyMoveHelper.copyToForeignTarget
>
> test/jdk/java/nio/file/Files/CopyMoveVariations.java line 135:
> 
>> 133:                     Files.setPosixFilePermissions(linkTarget, perms);
>> 134:                 else
>> 135:                     Files.setPosixFilePermissions(source, perms);
> 
> Should this be expanded to cover the permissions of the directory containing the source file, that's the case where the access(2) call may fail because the directory can't be updated.

>From what I can tell, `access(source, R_OK)` will fail if the parent directory does not confer adequate permissions to read the file. I would think it would be the parent directory of the target which would need to be checked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15501#discussion_r1329050142

From egahlin at openjdk.org  Fri Sep 22 13:06:34 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 22 Sep 2023 13:06:34 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v6]
In-Reply-To: <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <smFku3Vx_mbWxQL7HAZZwg6BHHHwnSd66xpvWROWA-o=.50072e65-dd6e-4db2-9481-af06485ca07c@github.com>
Message-ID: <5tdptBPPCTyNYn8wbZ1_bN52j8C-YRkWpmMksczutQs=.2700421a-3722-4d42-b186-482e38dba8d7@github.com>

On Tue, 19 Sep 2023 15:35:11 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into JDK-8308995
>  - More changes from review:
>    
>    I didn't like the name of the helper method 'checkForCommit' because it
>    doesn't indicate that it might commit the event.  I also don't like
>    'commitEvent' because it might not.  Since JFR events are sort of like a
>    queue I went with a name from collections and called it 'offer' so using
>    it is something like 'SocketReadEvent.offer(...)' which seems like it
>    gets the idea across better.  Also improved the javadoc for it.
>    
>    Removed the comments about being instrumented by JFR in
>    Socket.SocketInputStream and Socket.SocketOutputStream.
>    
>    I went ahead and moved the event commiting out of the finally block so
>    that we don't emit events when the read/write did not actually happen.
>    The bugid JDK-8310979 will be used to determine if more should be done
>    in this area.
>    
>    The implRead and implWrite were moved up with the other support methods
>    for read/write.
>  - less exception filtering when fetching socket read timeout
>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>  - Merge branch 'master' into JDK-8308995
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>    whitespace.
>  - some changes from review.
>    
>    read0() to implRead()
>    write0() to implWrite()
>    trailing whitespace
>  - fix copyright date
>  - Added micro benchmark to measure socket event overhead.
>  - Some changes from review.
>    
>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>    a reverse lookup when fetching the hostname of the remote address.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/607bd4ed...6db6fab4

The new implementation calls getSocketRemoteAddress() and getSOTimeout() regardless if the event duration exceeds the threshold or not. This adds unnecessary overhead. Most socket write/reads are not committed, only those that take more than 20 ms (by default). I think you need something like this:

if (SocketRead.shouldCommit(...)) {
  ...
}

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

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1731379349

From mcimadamore at openjdk.org  Fri Sep 22 13:44:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 13:44:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: <DJHFwQy2HM_sr-kPgIcu0nmF0mKbRdALL1l9Q8P8W4I=.788606ee-21c9-4758-9636-1fbe3b3fd5a4@github.com>

On Mon, 18 Sep 2023 14:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

src/java.base/share/classes/java/lang/foreign/Linker.java line 152:

> 150:  * <p>
> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 according to the
> 152:  * "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (all the examples provided

I have seen some discussion on this and I agree an authoritative link does not exist (I have searched for it in the past). I guess I'm not super wild about also including "AMD64 Architecture Processor Supplement". E.g. IMHO "System V Application Binary Interface" is more than enough?

src/java.base/share/classes/java/lang/foreign/Linker.java line 409:

> 407:  *
> 408:  * Variadic functions are C functions which can accept a variable number and type of arguments. They are declared with a
> 409:  * trailing ellipsis ({@code ...}) at the end of the formal parameter list, such as: {@code void foo(int x, ...);}.

Looking at the javadoc - it seems to me that the `;` after the declaration of `foo` leads to a bit of jarring as it is immediately followed by a period (`.`). Consider dropping that - or maybe put the declaration in a snippet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334395919
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334399541

From mcimadamore at openjdk.org  Fri Sep 22 14:06:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:06:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>

On Mon, 18 Sep 2023 14:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:

> 308: 
> 309:     /**
> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of

Suggestion:

     * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334428574

From mcimadamore at openjdk.org  Fri Sep 22 14:14:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:14:19 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
Message-ID: <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>

On Fri, 22 Sep 2023 14:03:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:
> 
>> 308: 
>> 309:     /**
>> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of
> 
> Suggestion:
> 
>      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of

Also, in the panama repo I see this:

Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.

Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334434230

From mcimadamore at openjdk.org  Fri Sep 22 14:14:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:14:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
Message-ID: <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>

On Fri, 22 Sep 2023 14:08:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 310:
>> 
>>> 308: 
>>> 309:     /**
>>> 310:      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byteSize()} of
>> 
>> Suggestion:
>> 
>>      * {@return a new memory segment with a {@linkplain MemorySegment#byteSize() byte size} of
>
> Also, in the panama repo I see this:
> 
> Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.
> 
> Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,

Panama repo change:
https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921

But, this code was altered in a follow up merge - maybe the merge was problematic?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334437424

From mcimadamore at openjdk.org  Fri Sep 22 14:34:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 14:34:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: <oPYjrd1ukCD4q5_oyC9l19-nC2-D-CYoWDBCi64JERw=.14468ec6-0670-405e-8918-cba2ec7daeb5@github.com>

On Mon, 18 Sep 2023 14:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

Marked as reviewed by mcimadamore (Reviewer).

test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java line 48:

> 46: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 47: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 48: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

native access not needed?

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstant.java line 51:

> 49: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 50: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 51: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

Is native access needed?

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverSlice.java line 52:

> 50: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 51: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 52: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })

Is --enable-native-access needed?

test/micro/org/openjdk/bench/java/lang/foreign/TestLoadBytes.java line 52:

> 50: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 51: @Fork(value = 1, jvmArgsAppend = {
> 52:         "-Dforeign.restricted=permit",

This seems obsolete? Maybe check other files too

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

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1640071167
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334460809
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334456849
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334455707
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334452394

From jvernee at openjdk.org  Fri Sep 22 14:34:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:34:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
Message-ID: <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>

On Fri, 22 Sep 2023 14:10:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also, in the panama repo I see this:
>> 
>> Allocates a memory segment with the given layout and initializes it with the bytes in the provided source memory segment.
>> 
>> Which seems more correct - e.g. more consistent with other allocation methods, and also more succinct (note that the first sentence is really what shows up in the method summary javadoc, so there is a certain interest in providing a quick description of what the method does,
>
> Panama repo change:
> https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921
> 
> But, this code was altered in a follow up merge - maybe the merge was problematic?

This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334462650

From jvernee at openjdk.org  Fri Sep 22 14:34:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:34:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
Message-ID: <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>

On Fri, 22 Sep 2023 14:31:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Panama repo change:
>> https://github.com/openjdk/panama-foreign/commit/06e2017883c939188103c4dd53185417a00b2921
>> 
>> But, this code was altered in a follow up merge - maybe the merge was problematic?
>
> This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.

I think I did the same when resolving the merge

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334463091

From jvernee at openjdk.org  Fri Sep 22 14:38:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:38:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
 <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
Message-ID: <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>

On Fri, 22 Sep 2023 14:31:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This was changed in the main line repo as a result of: https://github.com/openjdk/jdk/pull/14997 Since all the other methods were using `{@return ...}` I changed this new overload to that style as well.
>
> I think I did the same when resolving the merge

I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334468243

From jvernee at openjdk.org  Fri Sep 22 14:50:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 14:50:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <oPYjrd1ukCD4q5_oyC9l19-nC2-D-CYoWDBCi64JERw=.14468ec6-0670-405e-8918-cba2ec7daeb5@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <oPYjrd1ukCD4q5_oyC9l19-nC2-D-CYoWDBCi64JERw=.14468ec6-0670-405e-8918-cba2ec7daeb5@github.com>
Message-ID: <9eYdE4uXg5zGj4yfFRFYNwpHFMbA_25yqPOhgq6n7vA=.0a40fc9c-86e3-4fef-96f4-d68a82c07438@github.com>

On Fri, 22 Sep 2023 14:29:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java line 48:
> 
>> 46: @State(org.openjdk.jmh.annotations.Scope.Thread)
>> 47: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> 48: @Fork(value = 3, jvmArgsAppend = { "--enable-native-access=ALL-UNNAMED" })
> 
> native access not needed?

This class extends `CLayouts` which also creates some native method handles, so it's needed here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334484155

From jvernee at openjdk.org  Fri Sep 22 15:09:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:09:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <DJHFwQy2HM_sr-kPgIcu0nmF0mKbRdALL1l9Q8P8W4I=.788606ee-21c9-4758-9636-1fbe3b3fd5a4@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <DJHFwQy2HM_sr-kPgIcu0nmF0mKbRdALL1l9Q8P8W4I=.788606ee-21c9-4758-9636-1fbe3b3fd5a4@github.com>
Message-ID: <KSHkqBEQJgNhsMXBhNEqC3oIK5kE_ytOaYPm90cGW6M=.af0d34c8-912f-4f41-87cb-1e20a752297f@github.com>

On Fri, 22 Sep 2023 13:39:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 152:
> 
>> 150:  * <p>
>> 151:  * The following table shows some examples of how C types are modelled in Linux/x64 according to the
>> 152:  * "System V Application Binary Interface - AMD64 Architecture Processor Supplement" (all the examples provided
> 
> I have seen some discussion on this and I agree an authoritative link does not exist (I have searched for it in the past). I guess I'm not super wild about also including "AMD64 Architecture Processor Supplement". E.g. IMHO "System V Application Binary Interface" is more than enough?

Ok, I think I agree, given that we already name x64 as a platform.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334509092

From jvernee at openjdk.org  Fri Sep 22 15:20:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:20:05 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>

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

 - remove unneeded benchmark flags
 - Merge branch 'master' into JEP22
 - 8310659: The jar tool should support allowing access to restricted methods from executable jars
   
   Reviewed-by: mcimadamore
 - Avoid eager use of LibFallback in FallbackLinker static block
 - add missing space + reflow lines
 - Fix typo
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - 8315917: Passing struct by values seems under specified
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - Merge branch 'master' into JEP22
 - add code snippet
 - ... and 39 more: https://git.openjdk.org/jdk/compare/c90d6310...5b64181d

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=22
  Stats: 4255 lines in 253 files changed: 2191 ins; 1200 del; 864 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

From jvernee at openjdk.org  Fri Sep 22 15:20:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:20:08 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
Message-ID: <hbIu9kRU0D3DjTwO3t-LEsuysZ_7kQAUDrYATMfPlWw=.5ff69c27-4c26-46ca-9c58-77d9fc410196@github.com>

On Mon, 18 Sep 2023 14:17:30 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Avoid eager use of LibFallback in FallbackLinker static block

After some offline discussion, the changes for adding the `Enable-Native-Access` jar manifest attribute have now bee added too:

- commit: https://github.com/openjdk/jdk/pull/15103/commits/6b24e886588a32845249e6d684c5219c27dbf751
- Original PR: https://github.com/openjdk/panama-foreign/pull/843

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731594343

From mcimadamore at openjdk.org  Fri Sep 22 15:22:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 15:22:18 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
 <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
Message-ID: <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>

On Fri, 22 Sep 2023 14:35:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I think I did the same when resolving the merge
>
> I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.

I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334524306

From liach at openjdk.org  Fri Sep 22 15:33:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 22 Sep 2023 15:33:26 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
Message-ID: <XfRRTj6dhCFY_DMpshz7jJgrZYtiK7tB6rudGIEsCJs=.3ba6179c-1f01-486b-9448-be0afbc6c3ad@github.com>

On Fri, 22 Sep 2023 15:20:05 GMT, Jorn Vernee <jvernee at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains 49 commits:
> 
>  - remove unneeded benchmark flags
>  - Merge branch 'master' into JEP22
>  - 8310659: The jar tool should support allowing access to restricted methods from executable jars
>    
>    Reviewed-by: mcimadamore
>  - Avoid eager use of LibFallback in FallbackLinker static block
>  - add missing space + reflow lines
>  - Fix typo
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - 8315917: Passing struct by values seems under specified
>    
>    Reviewed-by: mcimadamore
>  - Merge branch 'master' into JEP22
>  - Merge branch 'master' into JEP22
>  - add code snippet
>  - ... and 39 more: https://git.openjdk.org/jdk/compare/c90d6310...5b64181d

Just curious, for `Enable-Native-Access`, if it's present on an automatic module `Automatic-Module-Name` jar, can it apply to only that automatic module instead of all unnamed modules?

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731612017

From jvernee at openjdk.org  Fri Sep 22 15:33:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 15:33:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v23]
In-Reply-To: <XfRRTj6dhCFY_DMpshz7jJgrZYtiK7tB6rudGIEsCJs=.3ba6179c-1f01-486b-9448-be0afbc6c3ad@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <0DuiWnffjpUzBASIfbHchpCP-b75VBI4evA6bb9o_eo=.25faef35-e2ef-47c3-bf97-ffd3dd2a8fd9@github.com>
 <XfRRTj6dhCFY_DMpshz7jJgrZYtiK7tB6rudGIEsCJs=.3ba6179c-1f01-486b-9448-be0afbc6c3ad@github.com>
Message-ID: <mMNs4RxhIlh0f3KBSMjOwUQgebvFMoiai6_OmmIE2-s=.5ea9d0b7-c4a3-4214-bb5b-6569ef12f24b@github.com>

On Fri, 22 Sep 2023 15:26:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Just curious, for `Enable-Native-Access`, if it's present on an automatic module `Automatic-Module-Name` jar, can it apply to only that automatic module instead of all unnamed modules?

No. It's only there for executable jars (run using `java -jar`), which are always placed on the class path.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1731617936

From jvernee at openjdk.org  Fri Sep 22 16:32:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:32:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
 <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
Message-ID: <TzjmlFVUEmuuFtG2SzjtMdRAJJBOqMlFMoccTvjzo_Q=.1470a36b-5e4d-411c-8475-5185c8ab2df0@github.com>

On Fri, 22 Sep 2023 15:19:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I don't mind changing it back to the old style, but I think the style should be consistent for all the allocateFrom overloads? So, I'd have to change all of them back.
>
> I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.

Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334600062

From jvernee at openjdk.org  Fri Sep 22 16:40:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:40:04 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v24]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <BG3XVmx5ljIqYQ-4ObGtM1Kuxq6MSiKFkbay8nWur28=.8ba7a80c-5ef0-42a1-ac53-7d95c5784405@github.com>

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/5b64181d..1c24f33e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=22-23

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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

From jvernee at openjdk.org  Fri Sep 22 16:40:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 22 Sep 2023 16:40:08 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <DJHFwQy2HM_sr-kPgIcu0nmF0mKbRdALL1l9Q8P8W4I=.788606ee-21c9-4758-9636-1fbe3b3fd5a4@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <DJHFwQy2HM_sr-kPgIcu0nmF0mKbRdALL1l9Q8P8W4I=.788606ee-21c9-4758-9636-1fbe3b3fd5a4@github.com>
Message-ID: <F0RWz5EpQBSVLNWEi8qaSWG-hzhC5CSvvl7tP-5Fis4=.7ffd2650-6e10-423f-9cfa-05235fd19340@github.com>

On Fri, 22 Sep 2023 13:41:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid eager use of LibFallback in FallbackLinker static block
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 409:
> 
>> 407:  *
>> 408:  * Variadic functions are C functions which can accept a variable number and type of arguments. They are declared with a
>> 409:  * trailing ellipsis ({@code ...}) at the end of the formal parameter list, such as: {@code void foo(int x, ...);}.
> 
> Looking at the javadoc - it seems to me that the `;` after the declaration of `foo` leads to a bit of jarring as it is immediately followed by a period (`.`). Consider dropping that - or maybe put the declaration in a snippet.

Will drop the period

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334604329

From mcimadamore at openjdk.org  Fri Sep 22 17:01:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 22 Sep 2023 17:01:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <TzjmlFVUEmuuFtG2SzjtMdRAJJBOqMlFMoccTvjzo_Q=.1470a36b-5e4d-411c-8475-5185c8ab2df0@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
 <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
 <TzjmlFVUEmuuFtG2SzjtMdRAJJBOqMlFMoccTvjzo_Q=.1470a36b-5e4d-411c-8475-5185c8ab2df0@github.com>
Message-ID: <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIYQmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>

On Fri, 22 Sep 2023 16:29:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I forgot about the change that went into mainline. Do you have a link of the latest javadoc? I'd like to check how the method summary looks.
>
> Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)

Ok, now I'm more convinced that the method summary really does look bad (or worse, compared to 20).

For instance [allocateFrom](https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfByte,byte...):


Returns a new memory segment with a byteSize() initialized with the provided E byte elements as specified by the provided layout (i.e. byte ordering, alignment and size).


(same is true for all the other array-accepting `allocateFrom` methods). This should be simplified to:


Returns a new memory segment initialized with the elements in the provided byte array.

(then, if we want to say that the initialization honors the endianness of the provided layout, we can do so in a followup para, but the method summary should be simple).

So, once all the array-accepting methods are fixed, the segment-accepting `allocateFrom` needs to be simplified to:


Returns a new memory segment initialized with the contents of the provided segment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1334627056

From alanb at openjdk.org  Sun Sep 24 14:44:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Sep 2023 14:44:10 GMT
Subject: RFR: 8316660: (fs) Files.lines implementation can use MemorSegment
 for file mapping [v7]
In-Reply-To: <yp3NtupNrRoZvvhJYNnI-Lj8Y9u55sDgqINTIW-Egn8=.80767e78-2b8a-4d12-af34-7ff40320824c@github.com>
References: <0q8diiS25yFCX86_UfwALWYys31a6QWXZuKu6V0qUw4=.ca4c4c42-aff3-4d5c-a5fc-24a2c07c39f9@github.com>
 <yp3NtupNrRoZvvhJYNnI-Lj8Y9u55sDgqINTIW-Egn8=.80767e78-2b8a-4d12-af34-7ff40320824c@github.com>
Message-ID: <4ogBit75r9O4azOFLyMDLgLnq6e9NN7xuZPT8loeoT4=.27092e3b-7cd5-4f4d-80db-e12aed3e3ccb@github.com>

On Thu, 21 Sep 2023 16:24:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes using a `MemorySegment` instead of a `ByteBuffer` in the `Files::lines` implementation (in the internal class `FileChannelLinesSpliterator`).
>> 
>> The old solution deterministically unmapped the `ByteBuffer` if closed. If not closed, the `ByteBuffer` would be GC:ed.
>> 
>> This proposal mimics the old behavior but may hold the mapped memory region slightly longer.
>> 
>> Tested and passed tier1, tier2, tier3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reformat

There is significant refactoring here that will take time to review, one thing that will need to be examined is the use of a shared Arena as I think the close op becomes O(N) on the number of platform threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/15814#issuecomment-1732588021

From alanb at openjdk.org  Sun Sep 24 17:21:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 24 Sep 2023 17:21:10 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <arHnNCfEU4YSOfHj-iRN4ICxZ3kBUqBy69JXJUqcDFQ=.a056a4d4-4abf-4386-a3e1-8fc85b835597@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
 <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>
 <gnHprO7sMCVHuRm1Cg-UUSqB3OhbJ_XHx9aPZgwGzOI=.6935a8af-a4a0-4611-9129-038e01a1ce2e@github.com>
 <arHnNCfEU4YSOfHj-iRN4ICxZ3kBUqBy69JXJUqcDFQ=.a056a4d4-4abf-4386-a3e1-8fc85b835597@github.com>
Message-ID: <U0summJd4sZZw7xh7aJhvey-6huRlYgTO54R4jAry24=.b72bdd43-f3ff-4d84-8a91-c7f4d7ac46b3@github.com>

On Thu, 21 Sep 2023 17:38:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Thanks for your input! Here is an updated patch, now using LinuxFileSystemProvider and the logic to use `statx` is now in the linux specific directory trees. The fallback code is unchanged (using `UnixNativeDispatcher`). This version never uses both `stat64` and `statx`. It only uses `statx` if its available and uses the older `stat64` otherwise.

I was chatting with @bplb about this change, mostly about testing and maintainability. We both agreed that this PR isn't the right place to do the refactoring, there is a lot disruptive changes needed to allow overriding of what is currently in the Unix* code. So if it's okay with you, we think go back the original/smaller change in UnixNativeDispatcher.c but use stat or statx, before both, as you have in the second iteration. Would that be okay with you?

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1732623818

From alanb at openjdk.org  Mon Sep 25 06:29:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 06:29:10 GMT
Subject: RFR: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing [v2]
In-Reply-To: <lX88CDGwV3iZkkp8DPWkfLSNRhcPzAAXqcCYixcvj9Y=.1e8735a6-eeb1-492a-af0d-304c14ad1e35@github.com>
References: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
 <lX88CDGwV3iZkkp8DPWkfLSNRhcPzAAXqcCYixcvj9Y=.1e8735a6-eeb1-492a-af0d-304c14ad1e35@github.com>
Message-ID: <jb7U5ZMm0Vhd5ws_mHnb9YSzWoIl5sjjA6My1Q8NxYE=.39976fae-456a-4588-8c73-dee7a1017355@github.com>

On Tue, 19 Sep 2023 20:03:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
>> 
>> - Corrected the path to the mapping files directory
>> - Made sure to fail if the directory path is incorrect
>> - Took care of `GB18030` alias, which is dynamically derived at runtime
>> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
>> - Excluded other failing tests for IBM charsets that do not have map files.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Included the failed directory location in the exception message

I suspect it was setup this way to allow the test tree be zipped up and the tests run without access to the src tree. In any case, the changes look okay, although a bit fragile to be reaching into the make/data tree for mapping data.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15807#pullrequestreview-1641399005

From jvernee at openjdk.org  Mon Sep 25 15:05:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:05:19 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v25]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <l6aHZlIJhqPA1h5fA-NiqK1dXwX3cM5_z7ba0fipekc=.46d2b555-dd55-4722-a940-8d29192c5891@github.com>

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

  Split note about byte order/alignment out of header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/1c24f33e..49bdd953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=23-24

  Stats: 83 lines in 1 file changed: 42 ins; 2 del; 39 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

From jvernee at openjdk.org  Mon Sep 25 15:05:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:05:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v22]
In-Reply-To: <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIYQmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <57W4fhF3ZFjp-PYI4CoFbNtbBfyh2c0S46bRz1D8T0c=.ff1a4e84-e440-43cf-9366-7624e68cc609@github.com>
 <mEh3uzGDnOT0GUcqnF4h3ofiqCW3ulxkodqwmld92tQ=.a9b6551d-cc25-499e-8f09-944a01d69d9b@github.com>
 <nhSARKaV2DAs3lonRJN-aLLryTiR-raNTmq7_w5LTAU=.90d2481c-85e3-40db-9590-4986d710f2a2@github.com>
 <opsjYPER7I6TpnfB03g3thR4y9dq0WFip1EYq8tylgg=.9ee35c02-8865-4941-9c57-a7bcc622e6d8@github.com>
 <t0e-hB-X_r-kCsQ4jNnWuuVMGa8U2YuXgQg-YnV8_jw=.83134d56-eada-43db-826a-42205304b415@github.com>
 <KjgVXuPyDQ4jfPCZBRXrcpv3U-yQ10GI5c-rpkvY8KI=.a308007c-90f9-4a29-9a6e-ef5064e2bb5f@github.com>
 <2i6hAPjL9qnofo6nFyUGjC9MBUxyYDtgWWDsvHtoBvc=.0a6f9585-319d-44e2-842e-adb61c80811a@github.com>
 <6XT6RHMxjba8n0P9rx7Pyy8Ot5VbdtupaTJikgYfeD0=.197bdfbe-e863-4529-97ed-c581c4a21d7d@github.com>
 <TzjmlFVUEmuuFtG2SzjtMdRAJJBOqMlFMoccTvjzo_Q=.1470a36b-5e4d-411c-8475-5185c8ab2df0@github.com>
 <17Hdk-QZiKVqpNzEV_v3vhd6uqDTdIdNpIY
 QmbETPNc=.ee3d0448-684d-4e67-abcf-f2af95bd1ea5@github.com>
Message-ID: <AyWPs9lloz3E8UmJJmrZwqxqp40d_PQaAqHXZemGIeE=.6be59c97-e222-47d3-ac78-911c00e6316a@github.com>

On Fri, 22 Sep 2023 16:58:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Here you go: https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout,java.lang.foreign.MemorySegment,java.lang.foreign.ValueLayout,long,long)
>
> Ok, now I'm more convinced that the method summary really does look bad (or worse, compared to 20).
> 
> For instance [allocateFrom](https://cr.openjdk.org/~jvernee/FFM_22_PR_v1/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfByte,byte...):
> 
> 
> Returns a new memory segment with a byteSize() initialized with the provided E byte elements as specified by the provided layout (i.e. byte ordering, alignment and size).
> 
> 
> (same is true for all the other array-accepting `allocateFrom` methods). This should be simplified to:
> 
> 
> Returns a new memory segment initialized with the elements in the provided byte array.
> 
> (then, if we want to say that the initialization honors the endianness of the provided layout, we can do so in a followup para, but the method summary should be simple).
> 
> So, once all the array-accepting methods are fixed, the segment-accepting `allocateFrom` needs to be simplified to:
> 
> 
> Returns a new memory segment initialized with the contents of the provided segment.

I've updated the 'header' of these methods, and instead added a more elaborated comment in a second paragraph. The single value `allocateFrom` methods had the same issue. I fixed those as well See: https://github.com/openjdk/jdk/pull/15103/commits/49bdd953eaed8732b59a803516355abc8df31fa3

Here is the re-generated javadoc: https://cr.openjdk.org/~jvernee/FFM_22_PR/v2/java.base/java/lang/foreign/SegmentAllocator.html#allocateFrom(java.lang.foreign.ValueLayout.OfInt,int...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336017587

From jvernee at openjdk.org  Mon Sep 25 15:09:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 15:09:09 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <sXc-0RthQRO6yKSaB8uAK-y4ZvlNHtkCtu286DMgapM=.47298303-b610-48f4-b021-c8f6317dca40@github.com>

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

  Tweak support for restricted methods
  
  Reviewed-by: jvernee, pminborg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/49bdd953..82a91258

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=24-25

  Stats: 34 lines in 10 files changed: 3 ins; 11 del; 20 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

From mcimadamore at openjdk.org  Mon Sep 25 16:47:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 16:47:26 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
In-Reply-To: <sXc-0RthQRO6yKSaB8uAK-y4ZvlNHtkCtu286DMgapM=.47298303-b610-48f4-b021-c8f6317dca40@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <sXc-0RthQRO6yKSaB8uAK-y4ZvlNHtkCtu286DMgapM=.47298303-b610-48f4-b021-c8f6317dca40@github.com>
Message-ID: <VD8v7bdeVJKaK2t5MmLQSmXePpN_Ja6_1b969NTy9y4=.bd831cdb-7b4c-46dd-906a-29de3d61b94e@github.com>

On Mon, 25 Sep 2023 15:09:09 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   Tweak support for restricted methods
>   
>   Reviewed-by: jvernee, pminborg

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 336:

> 334:      * {@return a new memory segment initialized with the contents of the provided segment.}
> 335:      * <p>
> 336:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elementCount}.

Suggestion:

     * The size of the allocated memory segment is {@code elementLayout.byteSize() * elementCount}.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 378:

> 376:      * {@return a new memory segment initialized with the elements in the provided byte array.}
> 377:      * <p>
> 378:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elements.length}.

Suggestion:

     * The size of the allocated memory segment is {@code elementLayout.byteSize() * elements.length}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336148784
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336149140

From mcimadamore at openjdk.org  Mon Sep 25 16:47:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 16:47:28 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v26]
In-Reply-To: <VD8v7bdeVJKaK2t5MmLQSmXePpN_Ja6_1b969NTy9y4=.bd831cdb-7b4c-46dd-906a-29de3d61b94e@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <sXc-0RthQRO6yKSaB8uAK-y4ZvlNHtkCtu286DMgapM=.47298303-b610-48f4-b021-c8f6317dca40@github.com>
 <VD8v7bdeVJKaK2t5MmLQSmXePpN_Ja6_1b969NTy9y4=.bd831cdb-7b4c-46dd-906a-29de3d61b94e@github.com>
Message-ID: <7g-pbFrnyMYtXK4894kdPWvsXJ79YdIp538CXAAiswU=.b65efe29-615e-45c3-abab-bd44d4c91bca@github.com>

On Mon, 25 Sep 2023 16:44:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak support for restricted methods
>>   
>>   Reviewed-by: jvernee, pminborg
>
> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 378:
> 
>> 376:      * {@return a new memory segment initialized with the elements in the provided byte array.}
>> 377:      * <p>
>> 378:      * The size of the allocated memory segment is the {@code elementLayout.byteSize() * elements.length}.
> 
> Suggestion:
> 
>      * The size of the allocated memory segment is {@code elementLayout.byteSize() * elements.length}.

Here and also in all the other array-accepting methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1336149494

From jvernee at openjdk.org  Mon Sep 25 16:54:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 25 Sep 2023 16:54:10 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>

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

  fix typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/82a91258..0244845a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=25-26

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 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

From alanb at openjdk.org  Mon Sep 25 17:51:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Sep 2023 17:51:52 GMT
Subject: RFR: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable [v7]
In-Reply-To: <LkZrurP9lQy0X8ZJQze7BbzJnydpp-5UQkq12tIbWzQ=.0611bcbb-185f-4df1-b67a-f0f1d7ac859f@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
 <LkZrurP9lQy0X8ZJQze7BbzJnydpp-5UQkq12tIbWzQ=.0611bcbb-185f-4df1-b67a-f0f1d7ac859f@github.com>
Message-ID: <5hu7CLNTRkBDZ1U3pNiHwFl7dzFy0zJN3qoXjg9RgOo=.85625461-dc4d-4813-969c-19dbad89068a@github.com>

On Mon, 18 Sep 2023 17:16:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Check that the source is readable before deleting the destination.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8073061: Check for POSIX permission support at top level of test

I don't have any other comments, I think you've got this to a good place.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15501#pullrequestreview-1642703760

From naoto at openjdk.org  Mon Sep 25 18:08:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 25 Sep 2023 18:08:13 GMT
Subject: Integrated: 8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is
 spuriously passing
In-Reply-To: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
References: <d9u_Ia9-8_Oj2XkSXBdNTIw1HLWA7XrlQHKaTlGISzo=.9f393069-8248-4bc8-9e8f-5cfb67a4b092@github.com>
Message-ID: <l6tqON-r3U2VjEhr7aO1ZCJaaadVTaEas86PMUj728w=.c92122f0-f172-4c5f-993d-4296fc15256d@github.com>

On Tue, 19 Sep 2023 01:01:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed the failing (well, false-positive) test case. Made the following changes to the test:
> 
> - Corrected the path to the mapping files directory
> - Made sure to fail if the directory path is incorrect
> - Took care of `GB18030` alias, which is dynamically derived at runtime
> - Provided `MS950_HKSCS.map`, which is simply a copy of `HKSCS2008.map`
> - Excluded other failing tests for IBM charsets that do not have map files.

This pull request has now been integrated.

Changeset: e3201d1d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e3201d1d13433857a1b34ff0ca93f9ae1a4e22aa
Stats:     20 lines in 2 files changed: 14 ins; 2 del; 4 mod

8310631: test/jdk/sun/nio/cs/TestCharsetMapping.java is spuriously passing

Reviewed-by: jlu, alanb

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

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

From alanb at openjdk.org  Tue Sep 26 08:00:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Sep 2023 08:00:13 GMT
Subject: RFR: 8316927: JFR: Move shouldCommit check earlier for socket
 events
In-Reply-To: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
References: <lJmLT7vnVUWORh-kLNd2eg2S80DFtmeC5vkNwDidess=.63e0b2d2-d7a6-4315-81f2-1031f227bf9e@github.com>
Message-ID: <VeiYDD2nMgOSIcTiDf5PAPJ2p1oq7F_rQSJhQ9Mn7E4=.300d384c-e5d3-46ac-a9af-0ce93557c1ed@github.com>

On Mon, 25 Sep 2023 16:57:46 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

The update looks okay. For SC, remoteAddress() just returns the address, it doesn't create a new ISA each time, unlike the Socket code.

At some point I think we should re-format SocketReadEvent to reduce the wildly long lines as it's really hard to look at the changes side-by-side right now. We also need to update sun.nio.ch.Socket{Input,Output}Stream to emit events as they are currently missed so the events are incomplete.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15908#pullrequestreview-1643604401

From bpb at openjdk.org  Tue Sep 26 15:31:27 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Sep 2023 15:31:27 GMT
Subject: Integrated: 8073061: (fs) Files.copy(foo, bar,
 REPLACE_EXISTING) deletes bar even if foo is not readable
In-Reply-To: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
References: <4TndZF8-xTbzyxbuVRzrXE9DN9jnkWHIMQw60RLVuxg=.44d9dd52-345c-46d9-b1f6-290a958da9a2@github.com>
Message-ID: <09m2EzMM0u40eaOr_Fmvfd_ngdOPh6_AV7DF_IrXAu0=.6a360402-b6c5-4a1d-8008-32c9b31a7e89@github.com>

On Thu, 31 Aug 2023 00:18:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Check that the source is readable before deleting the destination.

This pull request has now been integrated.

Changeset: 36ac8390
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36ac83904c9e81a01822b0e36ef677cae2808709
Stats:     322 lines in 5 files changed: 308 ins; 8 del; 6 mod

8073061: (fs) Files.copy(foo, bar, REPLACE_EXISTING) deletes bar even if foo is not readable

Reviewed-by: alanb

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

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

From psandoz at openjdk.org  Tue Sep 26 18:47:22 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 18:47:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
Message-ID: <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>

On Mon, 25 Sep 2023 16:54:10 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   fix typos

src/java.base/share/classes/java/lang/Module.java line 328:

> 326:                 System.err.printf("""
> 327:                         WARNING: A restricted method in %s has been called
> 328:                         WARNING: %s has been called%s in %s

Suggestion:

                        WARNING: %s has been called by %s in %s

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337640870

From psandoz at openjdk.org  Tue Sep 26 19:06:24 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 19:06:24 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
Message-ID: <erhq8NT_C3LMQeqINZsKb9y_YyVKIPyKaXY5mD1BkDU=.23a614ec-4ce1-4cd6-a8b5-1bf5c29daa75@github.com>

On Mon, 25 Sep 2023 16:54:10 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   fix typos

src/java.base/share/classes/java/lang/foreign/Linker.java line 735:

> 733:          *
> 734:          * @apiNote This linker option can not be combined with {@link #critical}.
> 735:          *

That seems more specification (that can be asserted on) then an informative note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337661700

From psandoz at openjdk.org  Tue Sep 26 21:20:23 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 21:20:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
Message-ID: <pUugcxcTtgEvh5tDxMPXadNN3HW_HmxvJGDBPCy4TP0=.a1d4e4f8-4d8f-411f-a35f-80fb4cad6bbf@github.com>

On Mon, 25 Sep 2023 16:54:10 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   fix typos

src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 152:

> 150:     private static long allocateMemoryWrapper(long size) {
> 151:         try {
> 152:             return UNSAFE.allocateMemory(size);

Since we now zero memory only when needed we should test very carefully.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337794211

From psandoz at openjdk.org  Tue Sep 26 21:31:23 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 21:31:23 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
Message-ID: <GEjH4vUQJXY9AxYUSzyEMYe3JzrzEDMRqABtfdIXuB0=.45b71654-fd28-43d4-b6ae-5be56505d3d4@github.com>

On Mon, 25 Sep 2023 16:54:10 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   fix typos

src/java.base/share/classes/java/lang/foreign/Linker.java line 35:

> 33: 
> 34: import java.lang.invoke.MethodHandle;
> 35: import java.nio.ByteOrder;

Unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337802958

From psandoz at openjdk.org  Tue Sep 26 22:02:20 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 26 Sep 2023 22:02:20 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
Message-ID: <BOtXkVFmSOJh7BS5Ca7r6SqfjTR7_3KFW6lX75cjtp8=.2c49da9e-93a9-4407-af30-63245028ed3a@github.com>

On Mon, 25 Sep 2023 16:54:10 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   fix typos

This looks good.

In the implementation the functional interfaces `BindingInterpreter.StoreFunc/LoadFunc` are package private, but are used in internal public signatures. This was previously like this and it's not a big deal but i recommend making those interfaces public.

We can also remove `@enablePreview` from `IndirectVarHandleTest`

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

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1645266436

From jvernee at openjdk.org  Wed Sep 27 00:26:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:26:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <GEjH4vUQJXY9AxYUSzyEMYe3JzrzEDMRqABtfdIXuB0=.45b71654-fd28-43d4-b6ae-5be56505d3d4@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
 <GEjH4vUQJXY9AxYUSzyEMYe3JzrzEDMRqABtfdIXuB0=.45b71654-fd28-43d4-b6ae-5be56505d3d4@github.com>
Message-ID: <uqVaKYeJHxki5ruiElytlo5bZWj2X5BkC-JhvQDKlEQ=.1a176684-8f6d-48c0-8069-ae77d0afa93b@github.com>

On Tue, 26 Sep 2023 21:28:43 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 35:
> 
>> 33: 
>> 34: import java.lang.invoke.MethodHandle;
>> 35: import java.nio.ByteOrder;
> 
> Unused?

Yes, I'll remove it.

> src/java.base/share/classes/java/lang/foreign/Linker.java line 735:
> 
>> 733:          *
>> 734:          * @apiNote This linker option can not be combined with {@link #critical}.
>> 735:          *
> 
> That seems more specification (that can be asserted on) then an informative note.

True. I'll fold it into the main spec body.

> src/java.base/share/classes/jdk/internal/foreign/NativeMemorySegmentImpl.java line 152:
> 
>> 150:     private static long allocateMemoryWrapper(long size) {
>> 151:         try {
>> 152:             return UNSAFE.allocateMemory(size);
> 
> Since we now zero memory only when needed we should test very carefully.

Yes. The `makeNativeSegment` is currently only called from ArenaImpl, which is also responsible for zeroing the memory.

I'll rename `makeNativeSegment` to `makeNativeSegmentNoZeroing` to make it extra clear for callers that memory will not be zeroed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337898179
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337898017
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337899265

From jvernee at openjdk.org  Wed Sep 27 00:33:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:33:37 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
 <2AguFuRwAmTfpUeFVU2toX7gEtL5VoWKOfkeiHLtpow=.084205ec-e2eb-4dd7-ada2-732b316f6a86@github.com>
Message-ID: <N147l9MMOo8vPbB4cPtUPfAlWxXh9_XtXTOw_sqrpHE=.c0774b2d-7c50-4c58-aaea-4b24f849597b@github.com>

On Tue, 26 Sep 2023 18:44:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typos
>
> src/java.base/share/classes/java/lang/Module.java line 328:
> 
>> 326:                 System.err.printf("""
>> 327:                         WARNING: A restricted method in %s has been called
>> 328:                         WARNING: %s has been called%s in %s
> 
> Suggestion:
> 
>                         WARNING: %s has been called by %s in %s
> 
> ?

The current code does the right thing, since in some cases the caller is `null` and the second `%s` should expand to an empty string. So  in the `caller == null` case, the message becomes:

    Class::method has been called in an unnamed module

There was also an offline suggestion to change it to:

    Class::method has been called by code in an unnamed module
    
Which I think is a good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1337902449

From jvernee at openjdk.org  Wed Sep 27 00:36:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:36:22 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v27]
In-Reply-To: <BOtXkVFmSOJh7BS5Ca7r6SqfjTR7_3KFW6lX75cjtp8=.2c49da9e-93a9-4407-af30-63245028ed3a@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <u2ILrTQWdhCLzLc1-iktO8Qqos6UCMgFLRmmaTO-rr8=.12a8d640-ae3c-4ac0-8524-ac5cb9fb0aae@github.com>
 <BOtXkVFmSOJh7BS5Ca7r6SqfjTR7_3KFW6lX75cjtp8=.2c49da9e-93a9-4407-af30-63245028ed3a@github.com>
Message-ID: <QAwr3v_OMlBNWVR3HDp7fQCf-43_Cbb5GEVBSHrOUiM=.f238f418-934e-4d0e-8f05-b28098b0c290@github.com>

On Tue, 26 Sep 2023 21:59:35 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> In the implementation the functional interfaces `BindingInterpreter.StoreFunc/LoadFunc` are package private, but are used in internal public signatures. This was previously like this and it's not a big deal but i recommend making those interfaces public.

This was fixed in the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/891

I'll add that commit to this patch as well.

> We can also remove `@enablePreview` from `IndirectVarHandleTest`

Good catch!

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1736481584

From jvernee at openjdk.org  Wed Sep 27 00:53:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 00:53:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>

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

 - Fix visibility issues
   
   Reviewed-by: mcimadamore
 - Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/0244845a..f6ab4dc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=26-27

  Stats: 11 lines in 6 files changed: 0 ins; 3 del; 8 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

From alanb at openjdk.org  Wed Sep 27 14:56:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 14:56:29 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
Message-ID: <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>

On Wed, 27 Sep 2023 00:53:25 GMT, Jorn Vernee <jvernee at openjdk.org> 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:
> 
>  - Fix visibility issues
>    
>    Reviewed-by: mcimadamore
>  - Review comments

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 640:

> 638:                 if (!enableNativeAccess.equals("ALL-UNNAMED")) {
> 639:                     throw new IllegalArgumentException("Only ALL-UNNAMED allowed as value for " + ENABLE_NATIVE_ACCESS);
> 640:                 }

I don't think throwing IAE is right here. It should call abort with a key for the error message. The value of enableNativeAccess can be used as the parameter for the message.

test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:

> 30:  * @modules jdk.incubator.vector
> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV

Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338733430
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338737145

From jvernee at openjdk.org  Wed Sep 27 14:56:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 14:56:31 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
Message-ID: <Wqp-e7_dPVfoj7zhRfN85OBUS-GtPTplw6-I52RY_Tw=.f52d972f-e44a-410d-8e08-4e37834c3beb@github.com>

On Wed, 27 Sep 2023 14:50:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix visibility issues
>>    
>>    Reviewed-by: mcimadamore
>>  - Review comments
>
> test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:
> 
>> 30:  * @modules jdk.incubator.vector
>> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
>> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV
> 
> Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.

Ok, I'll go over all the tests that I've changed and see if there are `@compile` tags that can be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338741350

From alanb at openjdk.org  Wed Sep 27 15:07:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 15:07:31 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
Message-ID: <QsJHJn4eZilAjA--DrmM2uXMl26fFnNiN7ix-Lumi1M=.88bbdd51-2186-49d0-919e-ed15f8821ae0@github.com>

On Wed, 27 Sep 2023 00:53:25 GMT, Jorn Vernee <jvernee at openjdk.org> 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:
> 
>  - Fix visibility issues
>    
>    Reviewed-by: mcimadamore
>  - Review comments

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1103:

> 1101:      * @throws WrongThreadException          if this method is called from a thread {@code T},
> 1102:      *                                       such that {@code isAccessibleBy(T) == false}.
> 1103:      * @throws UnsupportedOperationException if {@code charset} is not a {@linkplain StandardCharsets standard charset}.

The caller can fix/avoid the exception by providing another value for the argument so I think IAE is the unchecked exception for this case rather than UOE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338758920

From jvernee at openjdk.org  Wed Sep 27 16:15:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:15:30 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <QsJHJn4eZilAjA--DrmM2uXMl26fFnNiN7ix-Lumi1M=.88bbdd51-2186-49d0-919e-ed15f8821ae0@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <QsJHJn4eZilAjA--DrmM2uXMl26fFnNiN7ix-Lumi1M=.88bbdd51-2186-49d0-919e-ed15f8821ae0@github.com>
Message-ID: <A4XCFLZ08CCLg53kitG21s7eWfxgE6GwXb-GlVqgGUI=.01a5c4bc-ec2d-4222-a122-02e341938cdb@github.com>

On Wed, 27 Sep 2023 15:04:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix visibility issues
>>    
>>    Reviewed-by: mcimadamore
>>  - Review comments
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1103:
> 
>> 1101:      * @throws WrongThreadException          if this method is called from a thread {@code T},
>> 1102:      *                                       such that {@code isAccessibleBy(T) == false}.
>> 1103:      * @throws UnsupportedOperationException if {@code charset} is not a {@linkplain StandardCharsets standard charset}.
> 
> The caller can fix/avoid the exception by providing another value for the argument so I think IAE is the unchecked exception for this case rather than UOE.

I agree. I'll make the change for the following `CharSet` accepting methods: `MemorySegment::getString(long,Charset)`, `MemorySegment::setString(long,String,Charset)`, and `SegmentAllocator::allocateFrom(String,Charset)`. (Which should be all of them).

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 640:
> 
>> 638:                 if (!enableNativeAccess.equals("ALL-UNNAMED")) {
>> 639:                     throw new IllegalArgumentException("Only ALL-UNNAMED allowed as value for " + ENABLE_NATIVE_ACCESS);
>> 640:                 }
> 
> I don't think throwing IAE is right here. It should call abort with a key for the error message. The value of enableNativeAccess can be used as the parameter for the message.

Thanks for the suggestion! I'll switch this to using `abort` instead.

Side note: I don't believe I have to add all the different error message translations right? Only the English version?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338855648
PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338857229

From jvernee at openjdk.org  Wed Sep 27 16:28:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:28:25 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v29]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <oLxak1Re8-Hq6BWIZ_eCyG7EHGE8HaZIw_7FCLvJReM=.767668a3-3557-4e18-85c6-062bbe01b4d7@github.com>

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

 - Use IAE instead of UOE for unsupported char sets
 - Use abort instead of IEA when encountering wrong value for ENA attrib.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/f6ab4dc5..ea1b9c5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=27-28

  Stats: 18 lines in 7 files changed: 3 ins; 0 del; 15 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

From alanb at openjdk.org  Wed Sep 27 16:28:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 27 Sep 2023 16:28:27 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <A4XCFLZ08CCLg53kitG21s7eWfxgE6GwXb-GlVqgGUI=.01a5c4bc-ec2d-4222-a122-02e341938cdb@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <QsJHJn4eZilAjA--DrmM2uXMl26fFnNiN7ix-Lumi1M=.88bbdd51-2186-49d0-919e-ed15f8821ae0@github.com>
 <A4XCFLZ08CCLg53kitG21s7eWfxgE6GwXb-GlVqgGUI=.01a5c4bc-ec2d-4222-a122-02e341938cdb@github.com>
Message-ID: <-rSkX6AyCfpiqcZp0Hadw0js8mWAScaUlsvgj4Ng1HE=.9090bf00-70bc-4bb9-8bbb-faa6a2ad8805@github.com>

On Wed, 27 Sep 2023 16:12:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Side note: I don't believe I have to add all the different error message translations right? Only the English version?

That's right, the translations will be updated towards the end of the release.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338874028

From jvernee at openjdk.org  Wed Sep 27 16:50:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:50:33 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v30]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@github.com>

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

  drop unneeded @compile tags from jtreg tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/ea1b9c5f..2bc0a650

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=28-29

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 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

From jvernee at openjdk.org  Wed Sep 27 16:50:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 27 Sep 2023 16:50:34 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v28]
In-Reply-To: <Wqp-e7_dPVfoj7zhRfN85OBUS-GtPTplw6-I52RY_Tw=.f52d972f-e44a-410d-8e08-4e37834c3beb@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <9NvYUl5F19FDLsn14TCcO34nCEZZIt07H8iLHrpTbgY=.d375318e-73a4-43df-9526-264a0ee043bc@github.com>
 <34zxg0Er5UaZKlmKxpvQ0QxAv8CeXEp0pSemqPgKquo=.165c5ccd-2873-42e7-aefa-e9ba2e78f661@github.com>
 <Wqp-e7_dPVfoj7zhRfN85OBUS-GtPTplw6-I52RY_Tw=.f52d972f-e44a-410d-8e08-4e37834c3beb@github.com>
Message-ID: <ezVkm24aROyDq_w9aSVO69wm6mI3-jkNwuTb6JDiXzA=.b4c51bab-83a8-4e61-bdca-42457f71869c@github.com>

On Wed, 27 Sep 2023 14:52:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 32:
>> 
>>> 30:  * @modules jdk.incubator.vector
>>> 31:  * @compile -source ${jdk.version} TestRangeCheckHoistingScaledIV.java
>>> 32:  * @run main/othervm compiler.rangechecks.TestRangeCheckHoistingScaledIV
>> 
>> Not important but I assume the @compile line can be removed from a number of tests as it's no longer needed. It was needed for tests that didn't use @enablePreview.
>
> Ok, I'll go over all the tests that I've changed and see if there are `@compile` tags that can be removed

Besides the `compiler/rangechecks/TestRangeCheckHoistingScaledIV` test I found one other test that uses `@compile` in this manner: `java/lang/Thread/jni/AttachCurrentThread/AttachTest`. I've amended both.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1338910373

From duke at openjdk.org  Thu Sep 28 03:28:36 2023
From: duke at openjdk.org (duke)
Date: Thu, 28 Sep 2023 03:28:36 GMT
Subject: Withdrawn: 8305744: (ch) InputStream returned by
 Channels.newInputStream should have fast path for
 ReadbleByteChannel/WritableByteChannel
In-Reply-To: <LqAr1GACsVMRcLs__YwYacxX4nWB1Mvdj53Sd_T9SEg=.970981c7-0b4b-4b55-be69-fa553a5d2db6@github.com>
References: <LqAr1GACsVMRcLs__YwYacxX4nWB1Mvdj53Sd_T9SEg=.970981c7-0b4b-4b55-be69-fa553a5d2db6@github.com>
Message-ID: <-rasJt29LQyR-j_0Lo5JeS34NaSsVOmv0df20gi4mUQ=.08f83710-e814-4b4b-8d4c-a0333c3375cf@github.com>

On Fri, 7 Apr 2023 11:45:42 GMT, Markus KARG <duke at openjdk.org> wrote:

> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of ReadableByteChannel-to-WritableByteChannel transfers, where neither Channel is a FileChannel, but including special treatment of SelectableByteChannel.
> 
> *Without* this optimization, the JRE applies a loop where a temporary 16k byte array on the Java heap is used to transport the data between both channels. This implies that data is first transported from the source channel into the Java heap and then from the Java heap to the target channel. For most Channels, as these are NIO citizen, this implies two transfers between Java heap and OS resources, which is rather time consuming. As the data is in no way modified by transferTo(), the temporary allocation of valuable heap memory is just as unnecessary as both transfers to and from the heap. It makes sense to prevent the use of Java heap memory.
> 
> This optimization omits the byte array on the Java heap, effectively omitting the transfers to and from that array in turn. Instead, the transfer happens directly from Channel to Channel reusing a ByteBuffer taken from the JRE's internal buffer management utility which also has a size of 16k. Both measures make the transfer more efficient, as just the very essential resources are used, but not more.
> 
> Using JMH on an in-memory data transfer using custom Channels (to prevent interception by other optimizations already existing in transferTo()) it was possible to measure a 2,5% performance gain. While this does not sound much, just as the spared 16k of Java heap doesn't, we need to consider that this also means sparing GC pressure, power consumption and CO2 footprint, and we need to consider that it could be higher when using different (possibly third-party) kinds of custom Channels (as "real I/O" between heap and OS-resources is way slower than the RAM-to-RAM benchmark applied by me). As the change does not induce new, extraordinary risks compared to the existing source code, I think it is worth gaining that 2,5+ percent. Possibly there might exist some kind of scalable Java-implemented cloud service that is bound to exactly this loop and that transports very heavy traffic, those particular 2,5+ percent could be a huge amount of kWh or CO2 in absolute numbers. Even if not now, th
 ere might be in future.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Thu Sep 28 07:17:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 28 Sep 2023 07:17:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v30]
In-Reply-To: <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <7SpZ55G-FXPaGDEborDn2ZhxF6EUPUdG6J1p56GLYo0=.603f7708-0bd0-4ab9-992a-6aabdc216cc0@github.com>
Message-ID: <Irtq8KfO6f648x_a5fo1GAnUQ13eGNgdYm1NvaG70Po=.df452ff3-02dd-41db-8c4e-e470f1816b99@github.com>

On Wed, 27 Sep 2023 16:50:33 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   drop unneeded @compile tags from jtreg tests

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1648059254

From jvernee at openjdk.org  Thu Sep 28 12:05:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 28 Sep 2023 12:05:35 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v31]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <a0Zv0Irl7PnB4emn6JEyULuczOlbh3nQraSqBj-msLQ=.7e7566ca-df2e-479a-ba51-07b53cf5b51b@github.com>

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

 - Merge branch 'master' into JEP22
 - drop unneeded @compile tags from jtreg tests
 - Use IAE instead of UOE for unsupported char sets
 - Use abort instead of IEA when encountering wrong value for ENA attrib.
 - Fix visibility issues
   
   Reviewed-by: mcimadamore
 - Review comments
 - fix typos
 - Tweak support for restricted methods
   
   Reviewed-by: jvernee, pminborg
 - Split note about byte order/alignment out of header
 - review comments
 - ... and 49 more: https://git.openjdk.org/jdk/compare/3481ecb2...72650c44

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

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=30
  Stats: 4352 lines in 258 files changed: 2211 ins; 1190 del; 951 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

From duke at openjdk.org  Thu Sep 28 12:12:37 2023
From: duke at openjdk.org (Paul Wagland)
Date: Thu, 28 Sep 2023 12:12:37 GMT
Subject: RFR: 8316156: ByteArrayInputStream.transferTo causes
 MaxDirectMemorySize overflow [v6]
In-Reply-To: <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
References: <J4rS-z7_V05nzEbsrwwd42owFvrBHyNPGbLaVWUO-Tw=.378ea69b-6743-4205-a565-624a5825e885@github.com>
 <a_zGVtZ7xnjEKiT3mQie-bxu18y54bRznDtgi7hMpFw=.a0dec55a-8a01-43cf-bbcc-233b982700e3@github.com>
Message-ID: <KjCpNrsn1UzOv5VeBXo1FhIczzjvSmVZ4VMv4ZGoKwg=.4ce5a32f-4ff5-4578-8cae-285d7e1020b0@github.com>

On Tue, 19 Sep 2023 20:03:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `ByteArrayInputStream.transferTo` invoked with an `OutputStream` parameter which delegates to a `FileChannel` throws an `OutOfMemoryError` if the length of the `byte[]` wrapped by the `ByteArrayInputStream` exceeds `MaxDirectMemorySize`. This is because `FileChannel.write` uses `IOUtil.write` which creates a temporary direct buffer for writing. If the `byte[]` length is larger than `MaxDirectMemorySize`, then the temporary direct buffer allocation fails with an `OutOfMemoryError`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert BufferedInputStream changes; update test

@blpb / @AlanBateman : Do you know if this will this also be released to Java 17 and/or Java 21 service packs?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1739017905

From sgehwolf at openjdk.org  Thu Sep 28 12:36:26 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 28 Sep 2023 12:36:26 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v2]
In-Reply-To: <YIsEc_95Ku1GhonWFVtpBEfTjL5Q3-w_XgGXbp4gIvw=.8dba8dc5-6821-4b27-bcf5-00ec9536c345@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <YIsEc_95Ku1GhonWFVtpBEfTjL5Q3-w_XgGXbp4gIvw=.8dba8dc5-6821-4b27-bcf5-00ec9536c345@github.com>
Message-ID: <G5c1HtPYmSxpa8AZUjv4qPC7gLi7hYl3MCOgVDlf1QM=.bc6620d5-0db7-4283-8ac9-a38425bc2ca4@github.com>

On Thu, 21 Sep 2023 17:29:44 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

Sorry for the late reply. I was travelling.

> > Thanks for your input! Here is an updated patch, now using LinuxFileSystemProvider and the logic to use `statx` is now in the linux specific directory trees. The fallback code is unchanged (using `UnixNativeDispatcher`). This version never uses both `stat64` and `statx`. It only uses `statx` if its available and uses the older `stat64` otherwise.
> 
> I was chatting with @bplb about this change, mostly about testing and maintainability. We both agreed that this PR isn't the right place to do the refactoring, there is a lot disruptive changes needed to allow overriding of what is currently in the Unix* code. So if it's okay with you, we think go back the original/smaller change in UnixNativeDispatcher.c but use stat or statx, before both, as you have in the second iteration. Would that be okay with you?

Fair enough. Hopefully we can make progress on that third version then.

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1739070969

From jvernee at openjdk.org  Thu Sep 28 13:33:32 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 28 Sep 2023 13:33:32 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <qzoM3EchYzqLiPk5kItjHZA7MP2hyFT4Kj9tUbJW9_Y=.3d028ec1-cd3b-4c7d-8430-5ed97006e5b6@github.com>

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

  review @enablePreview from java/foreign/TestRestricted test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/72650c44..17dacbbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=30-31

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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

From bpb at openjdk.org  Fri Sep 29 02:21:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 02:21:13 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v2]
In-Reply-To: <Rrq90sEx1LPRXZEqzpMEIMoR7OiUqc7T9ms8Rsc8UnA=.327bd2c0-f2c1-4767-bfc8-2f3ae479f59f@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <Rrq90sEx1LPRXZEqzpMEIMoR7OiUqc7T9ms8Rsc8UnA=.327bd2c0-f2c1-4767-bfc8-2f3ae479f59f@github.com>
Message-ID: <uMYfw_dX2yvS8JNw9tP0TgIy350TaHJCNUQ5ifV3ZX8=.86db5e6a-1d45-45d8-80a7-1780339bd74b@github.com>

On Thu, 31 Aug 2023 23:07:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list,
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8315273: Add bug ID to test

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-1740222294

From sgehwolf at openjdk.org  Fri Sep 29 16:35:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 29 Sep 2023 16:35:09 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
Message-ID: <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>

> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
> 
> Testing:
> - [x] GHA (MacOS X failure seems unrelated)
> - [x] `java.nio` tests.
> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
> 
> Thoughts?

Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:

 - Wrap copy_statx_attributes with ifdef __linux__
 - Fix compile warnings.
 - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15792/files
  - new: https://git.openjdk.org/jdk/pull/15792/files/3ead43a1..070c413a

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

  Stats: 920 lines in 14 files changed: 228 ins; 649 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/15792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15792/head:pull/15792

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

From sgehwolf at openjdk.org  Fri Sep 29 16:35:15 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 29 Sep 2023 16:35:15 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux
In-Reply-To: <U0summJd4sZZw7xh7aJhvey-6huRlYgTO54R4jAry24=.b72bdd43-f3ff-4d84-8a91-c7f4d7ac46b3@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <wgjr3wenJAxTeO2QvS_k3oq06vzN7FHt2i9-hr9bzok=.120ef1a8-f521-468a-9607-05cdad21e89b@github.com>
 <e8yFevPeifNIU_ft3DkqJAAZw92yZd9GNaaNFSlh2FQ=.1da80bbc-112b-4fbe-8f28-db39dff10a2d@github.com>
 <gnHprO7sMCVHuRm1Cg-UUSqB3OhbJ_XHx9aPZgwGzOI=.6935a8af-a4a0-4611-9129-038e01a1ce2e@github.com>
 <arHnNCfEU4YSOfHj-iRN4ICxZ3kBUqBy69JXJUqcDFQ=.a056a4d4-4abf-4386-a3e1-8fc85b835597@github.com>
 <U0summJd4sZZw7xh7aJhvey-6huRlYgTO54R4jAry24=.b72bdd43-f3ff-4d84-8a91-c7f4d7ac46b3@github.com>
Message-ID: <pQ2lQ6P2oUn8KTxMkusByjjBQSI1JcTlPZcetEOaJww=.1aceb826-1dd8-457c-9fed-abc482d6e39b@github.com>

On Sun, 24 Sep 2023 17:18:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman @gnu-andrew Thanks for your input! Here is an updated patch, now using LinuxFileSystemProvider and the logic to use `statx` is now in the linux specific directory trees. The fallback code is unchanged (using `UnixNativeDispatcher`). This version never uses both `stat64` and `statx`. It only uses `statx` if its available and uses the older `stat64` otherwise. 
>> 
>> On a Linux system that has `statx` (using `LastModified` from the bug):
>> 
>> # grep test.txt strace_out.log 
>> execve("./jdk-22.0.0+0/bin/java", ["./jdk-22.0.0+0/bin/java", "LastModified", "test.txt"], 0xffffe07f0b98 /* 42 vars */) = 0
>> [pid 17058] statx(AT_FDCWD, "test.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
>> # stat test.txt 
>>   File: test.txt
>>   Size: 0         	Blocks: 0          IO Block: 65536  regular empty file
>> Device: fd00h/64768d	Inode: 100734611   Links: 1
>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>> Context: unconfined_u:object_r:admin_home_t:s0
>> Access: 2023-09-21 13:14:00.464356794 -0400
>> Modify: 2000-01-01 01:01:00.000000000 -0500
>> Change: 2023-09-21 13:17:13.835434277 -0400
>>  Birth: 2023-09-21 13:12:13.033760507 -0400
>> 
>> 
>> On a Linux system that doesn't have `statx`:
>> 
>> # grep 'stat' strace_out.log  | grep testme
>> [pid  8302] stat("testme.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>> # stat testme.txt 
>>   File: ?testme.txt?
>>   Size: 0         	Blocks: 0          IO Block: 65536  regular empty file
>> Device: fd00h/64768d	Inode: 100822778   Links: 1
>> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>> Context: unconfined_u:object_r:admin_home_t:s0
>> Access: 2023-09-21 13:09:46.459640944 -0400
>> Modify: 2000-01-01 01:01:00.000000000 -0500
>> Change: 2023-09-21 13:16:08.142395814 -0400
>>  Birth: -
>> 
>> Please let me know what you think!
>> 
>> FWIW, I've compiled this fine on Alpine Linux, so there aren't any glibc guards anymore.
>
>> Thanks for your input! Here is an updated patch, now using LinuxFileSystemProvider and the logic to use `statx` is now in the linux specific directory trees. The fallback code is unchanged (using `UnixNativeDispatcher`). This version never uses both `stat64` and `statx`. It only uses `statx` if its available and uses the older `stat64` otherwise.
> 
> I was chatting with @bplb about this change, mostly about testing and maintainability. We both agreed that this PR isn't the right place to do the refactoring, there is a lot disruptive changes needed to allow overriding of what is currently in the Unix* code. So if it's okay with you, we think go back the original/smaller change in UnixNativeDispatcher.c but use stat or statx, before both, as you have in the second iteration. Would that be okay with you?

@AlanBateman Please take another look. It's now back with using the native only. It only does a single `statx` or `stat64` call depending on support of the underlying system.

Example:

$ strace -f ./java LastModified test.txt 2>&1 | grep stat | grep test.txt
[pid 200843] stat("test.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
$ strace -f ./java LastModified test.txt 2>&1 | grep stat | grep test.txt
[pid 200879] statx(AT_FDCWD, "test.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0


Long term something like the [v2 patch](https://github.com/jerboaa/jdk/compare/d75d9774c806e4bf73caa69cd78c31a132e4c812..JDK-8316304-statx-create-time-new-v2) seems more appropriate, IMO.

Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/15792#issuecomment-1741010079

From bpb at openjdk.org  Fri Sep 29 16:54:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 16:54:23 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException
Message-ID: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>

The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

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

Commit messages:
 - 8317128: java/nio/file/Files/CopyAndMove.java failed with AccessDeniedException

Changes: https://git.openjdk.org/jdk/pull/15991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317128
  Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15991/head:pull/15991

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

From bpb at openjdk.org  Fri Sep 29 17:04:19 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 17:04:19 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
Message-ID: <fT0mUNftFu38_6CoxkQ9JAAtcRHffkVg1Ioiw48csDA=.a4c5048b-fe1a-45c1-adc2-ce681830ce66@github.com>

On Fri, 29 Sep 2023 16:35:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - Fix compile warnings.
>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 239:

> 237: #if defined(__linux__)
> 238: typedef int statx_func(int dirfd, const char *restrict pathname, int flags,
> 239:                  unsigned int mask, struct statx *restrict statxbuf);

Align `unsigned int mask` under `int dirfd`.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 280:

> 278: #if defined(__linux__)
> 279: static int statx_wrapper(int dirfd, const char *restrict pathname, int flags,
> 280:                  unsigned int mask, struct statx *restrict statxbuf, int follow_symlink) {

Align as done elsewhere in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1341604877
PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1341606589

From bpb at openjdk.org  Fri Sep 29 17:29:30 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 29 Sep 2023 17:29:30 GMT
Subject: RFR: 8316304: (fs) Add support for
 BasicFileAttributes.creationTime() for Linux [v3]
In-Reply-To: <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
References: <JckwfE9dvjClpuFL8OgoQLcClMGZKYDXKQOY04mN2lU=.fa5d0cec-be84-4ff8-aa18-c5f7ff3288c7@github.com>
 <tOu7sNDrhXduwY9l8LkciPZuqGdlTmSICZahGwBxj1M=.6430bb49-92c6-4ec6-9b8f-c87968160756@github.com>
Message-ID: <nxBzWO5wEjuUfhxJ7Yj_j9Om2yqWzl0CLJB5h-D-ryQ=.d8ac9760-f6b7-404b-b6d7-dc834dc0647f@github.com>

On Fri, 29 Sep 2023 16:35:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this nio change which adds `BasicFileAttributes.creationTime()` support for Linux by means of the `statx` Linux specific system call. The patch does a dynamic lookup of the function and if it is available, uses it to set the support birth time capability in `UnixNativeDispatcher`. When `statx` is not available, it won't use it and fall back to the old behaviour on such systems. It should, however, compile fine on Linux systems not supporting the `statx` system call.
>> 
>> Testing:
>> - [x] GHA (MacOS X failure seems unrelated)
>> - [x] `java.nio` tests.
>> - [x] Manual builds and tests on older glibc versions (2.17 => fallback, 2.28+ => works). Compiles fine and falls back to the not supported case as it was before this patch.
>> 
>> Thoughts?
>
> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:
> 
>  - Wrap copy_statx_attributes with ifdef __linux__
>  - Fix compile warnings.
>  - 8316304: (fs) Add support for BasicFileAttributes.creationTime() for Linux

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 34:

> 32:  */
> 33: 
> 34: import java.lang.reflect.Method;

Instead of using reflective access, would it be possible to use the "os.version" property and a minimum kernel version (4.11?)?


jshell> System.getProperty("os.version")
$1 ==> "5.19.0-50-generic"

jshell> 
bpb at bpb-vb-u2204:~$ uname -a
Linux bpb-vb-u2204 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15792#discussion_r1341635701

From alanb at openjdk.org  Sat Sep 30 06:27:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 30 Sep 2023 06:27:39 GMT
Subject: RFR: 8317128: java/nio/file/Files/CopyAndMove.java failed with
 AccessDeniedException
In-Reply-To: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
References: <kX0_D7ZNSgtZRXiBIpLw4wWy9ToFTadVe5bqAanP0Mg=.94edb3ec-5335-4466-970a-497c67a9bf9e@github.com>
Message-ID: <5ar7nVuS0bVkQh4kZVvY7Tx1AcBCiAuawllebwsyZYY=.2848d320-d2dc-4433-863b-bcfd9120ea21@github.com>

On Fri, 29 Sep 2023 15:57:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The change #15501 removed explicit throwing of a `FileAlreadyExistsException` in `copyToForeignTarget` for non-directories when the target exists and `REPLACE_EXISTING` is not specified, instead relying on `FileChannel.open` eventually to throw this exception. The test, however, reuses the same file path, and on Windows `CreateFile`, which is invoked by `open`, can throw an `AccessDeniedException` if the file exists and has been marked for deletion but not yet actually deleted. This change proposes to reinstate explicitly throwing a FAEE.

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 150:

> 148:             Files.createDirectory(target);
> 149:         } else {
> 150:             try (InputStream in = Files.newInputStream(source)) {

If we are you reverting that then I assume you also should revert the change to L147 too, meaning replaceExistingOrEmpty() isn't needed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15991#discussion_r1341917792

From duke at openjdk.org  Sat Sep 30 15:52:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 30 Sep 2023 15:52:55 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
In-Reply-To: <qzoM3EchYzqLiPk5kItjHZA7MP2hyFT4Kj9tUbJW9_Y=.3d028ec1-cd3b-4c7d-8430-5ed97006e5b6@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <qzoM3EchYzqLiPk5kItjHZA7MP2hyFT4Kj9tUbJW9_Y=.3d028ec1-cd3b-4c7d-8430-5ed97006e5b6@github.com>
Message-ID: <eaBqLoVEG87e4H1kGu0_5-TnGP2Im0HmCOIoELiQWIw=.4a585342-11e9-4bfe-b653-ce2e2f784bc3@github.com>

On Thu, 28 Sep 2023 13:33:32 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   review @enablePreview from java/foreign/TestRestricted test

Maybe?include <https://github.com/openjdk/panama-foreign/pull/864>?

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1741795291

From jvernee at openjdk.org  Sat Sep 30 16:22:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 30 Sep 2023 16:22:56 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
 [v32]
In-Reply-To: <qzoM3EchYzqLiPk5kItjHZA7MP2hyFT4Kj9tUbJW9_Y=.3d028ec1-cd3b-4c7d-8430-5ed97006e5b6@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <qzoM3EchYzqLiPk5kItjHZA7MP2hyFT4Kj9tUbJW9_Y=.3d028ec1-cd3b-4c7d-8430-5ed97006e5b6@github.com>
Message-ID: <urlnchosGXlr1pCp6xHom8cjNtgI6kzto8z_PsdNpGA=.53746de5-78d8-487c-b278-9ca1f17d1d79@github.com>

On Thu, 28 Sep 2023 13:33:32 GMT, Jorn Vernee <jvernee at openjdk.org> 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 one additional commit since the last revision:
> 
>   review @enablePreview from java/foreign/TestRestricted test

> Maybe include [openjdk/panama-foreign#864](https://github.com/openjdk/panama-foreign/pull/864)?

The leftover implementation-only changes will be ported over separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1741806316