From bpb at openjdk.org  Wed Feb  5 02:03:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Feb 2025 02:03:15 GMT
Subject: RFR: 8349383: (fs) FileTreeWalker.next() superfluous null check of
 visit() return value
Message-ID: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>

Remove the `do-while` loop which was conditional on `Event` being `null` when it can never be so.

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

Commit messages:
 - 8349383: (fs) FileTreeWalker.next() superfluous null check of visit() return value

Changes: https://git.openjdk.org/jdk/pull/23453/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349383
  Stats: 41 lines in 1 file changed: 6 ins; 12 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/23453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23453/head:pull/23453

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

From djelinski at openjdk.org  Wed Feb  5 11:41:15 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 5 Feb 2025 11:41:15 GMT
Subject: RFR: 8349383: (fs) FileTreeWalker.next() superfluous null check of
 visit() return value
In-Reply-To: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>
References: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>
Message-ID: <MStTtpc9vPVscqGPX-RePRyEndCJ0EI0FNT88UvVAAQ=.cd01a96f-1160-4556-a4e6-e94589474cc1@github.com>

On Wed, 5 Feb 2025 01:57:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `do-while` loop which was conditional on `Event` being `null` when it can never be so.

LGTM.

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23453#pullrequestreview-2595417243

From bpb at openjdk.org  Wed Feb  5 16:21:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Feb 2025 16:21:02 GMT
Subject: RFR: 8349383: (fs) FileTreeWalker.next() superfluous null check of
 visit() return value
In-Reply-To: <MStTtpc9vPVscqGPX-RePRyEndCJ0EI0FNT88UvVAAQ=.cd01a96f-1160-4556-a4e6-e94589474cc1@github.com>
References: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>
 <MStTtpc9vPVscqGPX-RePRyEndCJ0EI0FNT88UvVAAQ=.cd01a96f-1160-4556-a4e6-e94589474cc1@github.com>
Message-ID: <udtmGnOtAtYeAAPMUpoYHd8ITxKhn1NfWLJYoA4tn6E=.406d8620-45e5-476f-9a1b-898fa9ae0de7@github.com>

On Wed, 5 Feb 2025 11:38:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> LGTM.

Thanks, @djelinski.

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

PR Comment: https://git.openjdk.org/jdk/pull/23453#issuecomment-2637386557

From bpb at openjdk.org  Wed Feb  5 21:43:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Feb 2025 21:43:15 GMT
Subject: Integrated: 8349383: (fs) FileTreeWalker.next() superfluous null check
 of visit() return value
In-Reply-To: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>
References: <o22riaGFVy30NXmqQT5YU4bpuxqdpdZKqc5qd8To5TE=.f64aab2e-5189-4209-a9a7-a064203e1769@github.com>
Message-ID: <ZgNXyh8eUas_aybxpp3EE9RdykffXgEhodZSZOOl_Io=.a4eb7b70-8108-4d30-927c-3abbc76c4ef8@github.com>

On Wed, 5 Feb 2025 01:57:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the `do-while` loop which was conditional on `Event` being `null` when it can never be so.

This pull request has now been integrated.

Changeset: b499c827
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b499c827a512fb209a806d95b97df0f5932a29c0
Stats:     41 lines in 1 file changed: 6 ins; 12 del; 23 mod

8349383: (fs) FileTreeWalker.next() superfluous null check of visit() return value

Reviewed-by: djelinski

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

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

From kcr at openjdk.org  Fri Feb  7 15:34:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:27 GMT
Subject: [jdk24] RFR: 8346972: Test
 java/nio/channels/FileChannel/LoopingTruncate.java fails sometimes with
 IOException: There is not enough space on the disk
In-Reply-To: <Hdcx9siCQ-lXnGn5WXA3BS9MRT3-ZYjatmoThutHLrQ=.2528b105-0b6c-4c03-8490-5e057d350337@github.com>
References: <Hdcx9siCQ-lXnGn5WXA3BS9MRT3-ZYjatmoThutHLrQ=.2528b105-0b6c-4c03-8490-5e057d350337@github.com>
Message-ID: <8Sn67vZpec7Ek9XrNBoJLYu_iK1Z9Fc7ReVPCAYpaqw=.6387df3a-4484-4100-a45b-f884bc729c78@github.com>

On Tue, 14 Jan 2025 01:41:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4e0ffda5](https://github.com/openjdk/jdk/commit/4e0ffda5b1d82449d2d6f639be7641b69d6cb520) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24. This backport make test more rubustness, test-fix only, no risk.
> 
> Thanks!

As we are now in the [Release Candidate phase of JDK 24](https://openjdk.org/projects/jdk/24/), this fix is no longer suitable for JDK 24. See [JEP 3](https://openjdk.org/jeps/3) for more information.

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

PR Comment: https://git.openjdk.org/jdk/pull/23094#issuecomment-2643256457

From kcr at openjdk.org  Fri Feb  7 15:34:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:27 GMT
Subject: [jdk24] Withdrawn: 8346972: Test
 java/nio/channels/FileChannel/LoopingTruncate.java fails sometimes with
 IOException: There is not enough space on the disk
In-Reply-To: <Hdcx9siCQ-lXnGn5WXA3BS9MRT3-ZYjatmoThutHLrQ=.2528b105-0b6c-4c03-8490-5e057d350337@github.com>
References: <Hdcx9siCQ-lXnGn5WXA3BS9MRT3-ZYjatmoThutHLrQ=.2528b105-0b6c-4c03-8490-5e057d350337@github.com>
Message-ID: <PdRvqcknJYOJBttSk5wuv5cDKgaHzzqxlJq2xQQ5Ui8=.abac7677-113c-48f0-8985-9ddbcb64af11@github.com>

On Tue, 14 Jan 2025 01:41:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4e0ffda5](https://github.com/openjdk/jdk/commit/4e0ffda5b1d82449d2d6f639be7641b69d6cb520) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24. This backport make test more rubustness, test-fix only, no risk.
> 
> Thanks!

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Fri Feb  7 15:34:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:35 GMT
Subject: [jdk24] Withdrawn: 8347171: (dc)
 java/nio/channels/DatagramChannel/InterruptibleOrNot.java fails with virtual
 thread factory
In-Reply-To: <7kT3-oGr1Z8kzkhzXT4o6V0pARyqeDkLjHowIzwhCmE=.63ac6a5d-428a-49ba-8d45-1f61d27d56d6@github.com>
References: <7kT3-oGr1Z8kzkhzXT4o6V0pARyqeDkLjHowIzwhCmE=.63ac6a5d-428a-49ba-8d45-1f61d27d56d6@github.com>
Message-ID: <z1dhDSIEbJyr8GXoWX9ZqgXICRuj8c9BoYJaSkG1JJk=.152d9368-d497-414d-be1a-45f378b36214@github.com>

On Mon, 13 Jan 2025 03:13:48 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ef77cdd](https://github.com/openjdk/jdk/commit/1ef77cdd51b91f6d6d3367444a37a3f0f2e4bc99) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> This backport make test more robustness, test-fix only, no risk,
> 
> Thanks!

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Fri Feb  7 15:34:34 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 7 Feb 2025 15:34:34 GMT
Subject: [jdk24] RFR: 8347171: (dc)
 java/nio/channels/DatagramChannel/InterruptibleOrNot.java fails with virtual
 thread factory
In-Reply-To: <7kT3-oGr1Z8kzkhzXT4o6V0pARyqeDkLjHowIzwhCmE=.63ac6a5d-428a-49ba-8d45-1f61d27d56d6@github.com>
References: <7kT3-oGr1Z8kzkhzXT4o6V0pARyqeDkLjHowIzwhCmE=.63ac6a5d-428a-49ba-8d45-1f61d27d56d6@github.com>
Message-ID: <Ac7COZTRFfzalgjE_4Y_p3BYIkFa44bbWj6917xqAs8=.af234a0d-ec7a-46fa-9b6b-f61ae0f46dee@github.com>

On Mon, 13 Jan 2025 03:13:48 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1ef77cdd](https://github.com/openjdk/jdk/commit/1ef77cdd51b91f6d6d3367444a37a3f0f2e4bc99) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk24.
> 
> This backport make test more robustness, test-fix only, no risk,
> 
> Thanks!

As we are now in the [Release Candidate phase of JDK 24](https://openjdk.org/projects/jdk/24/), this fix is no longer suitable for JDK 24. See [JEP 3](https://openjdk.org/jeps/3) for more information.

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

PR Comment: https://git.openjdk.org/jdk/pull/23060#issuecomment-2643256598

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
Message-ID: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>

This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.

In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.

To ensure quality...
* ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
* ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

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

Commit messages:
 - Merge master
 - Copyright (C) 2025
 - @Override
 - Draft: CharSequence.getChars

Changes: https://git.openjdk.org/jdk/pull/21730/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343110
  Stats: 79 lines in 5 files changed: 64 ins; 9 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21730.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21730/head:pull/21730

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

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <dsUpWwgPLBSQk7wReV_AgqdtcHH1K4OPRGTKvjss7Ec=.29bf8d87-bbd7-4902-91fa-0123923a80a5@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

FYI @liach @bokken @eirbjo @robtimus @parttimenerd

Kindly asking anybody's contribution to the ongoing discussion on the core-devs mailing list. Thanks you.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439635920
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2558392238

From liach at openjdk.org  Sun Feb  9 18:41:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

Sorry for belated mail response, but I think we should design the API to not take source start/end. I think JIT can escape analysis the new String in practice.

Hi Markus, I recommend to continue the discussion on the mailing list instead of on GitHub. Note that GitHub pull requests are only forwarded to the mailing list when it's ready for review, and this proposal is way too early. (And the CSR is too early, too: we should agree on an API surface, such as exception contracts, first)

Sorry that no one has responded to you yet, but many engineers are busy with other areas, such as pushing the JEPs (as you see, we have a huge number of candidate/submitted JEPs right now, and JDK 24 RDP1 is just 6 weeks away). They are monitoring your core-libs thread, stay assured!

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439641840
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439740522

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <mnYTzE2ZFnmuNbOub0FURZ07ib19OLHB4WwHyBCR41s=.5a4d68d7-c777-41f4-987b-5121b408665d@github.com>
Message-ID: <91jI-SwtJz_LQk4SnzNF5xKeTPQoOOEp4HmYcEHmgqI=.028c8bdd-a630-427a-b544-3d90553d8080@github.com>

On Sat, 26 Oct 2024 16:26:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sorry for belated mail response, but I think we should design the API to not take source start/end. I think JIT can escape analysis the new String in practice.

Chen, thank you for chiming in! There is nothing to be sorry, I was just posting *drafts* so far! ? 

Regarding your actual question, I do understand your idea and while originally I had the same in mind (it really *is* appealing!), I came up with a draft using the original `String.getChars()` signature instead, due to the following drawbacks:
* There might exist (possibly lotsof) `CharSequence.getChars(int, int, char[], int)` implementations already, as this problem (and the idea how to solve it) is anything but new. At least such implementations are `String`, `StringBuilder` and `StringBuffer`. If we come up with a different signature, then **none** of these already existing performance boosters will get used by `Reader.of(CharSequence)` automatically - at least until they come up with alias methods. Effectively this leads to (possibly lots) of alias methods. At least it leads to alias methods in `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`. In contrast, when keeping the signature copied from `String.getChars`, chances are good that (possibly lots of) implementations will *instantly* be supported by `Reader.of(CharSequence)` without alias methods. At least, `String`, `StringBuilder` and `StringBuffer` will be.
* Since decades people are now very used to `StringBuilder.getChars(int, int, char[], int)`, so (possibly a lot of) people might simply *expect* us to come up with that lengthy signature. These people might be rather confused (if not to say frustrated) when we now force them to write an intermediate `subSequence(int, int)` for something that was "such simple" before.
* Custom implementations of `CharSequence.subSequence` could come up with the (performance-wise "bad") idea of creating **copies** instead of views. At least it seems like `AbstractStringBuilder` is doing that, so chances are "good" that custom libs will do that, too. For example, because they need it for safety. Or possibly, because they have a technical reason that *enforces* a copy. That would (possibly massively, depending on the actual class) spoil the idea of performance-boosting this PR is actually all about.

> Hi Markus, I recommend to continue the discussion on the mailing list instead of on GitHub. Note that GitHub pull requests are only forwarded to the mailing list when it's ready for review, and this proposal is way too early. (And the CSR is too early, too: we should agree on an API surface, such as exception contracts, first)
> 
> Sorry that no one has responded to you yet, but many engineers are busy with other areas, such as pushing the JEPs (as you see, we have a huge number of candidate/submitted JEPs right now, and JDK 24 RDP1 is just 6 weeks away). They are monitoring your core-libs thread, stay assured!

@liach Agreed with all you say, but actually: I **did not expect** any response - in particular on a weekend!

I do not know why apparently people started to *review* the **draft** documents. I just filed it for no other purpose than *taking note of its existence*. ?  I thought it is pretty clear to everybody that draft means **"do not review"**. At least this is how I used draft documents in the past 30 years. ?

So it seems there was a misunderstanding here regarding my **drafts**. My intention ever was and still is to first finish the discussion *about alternatives (A)...(E)* **on the core-lib mailing list** *first*. My PR and CSR **drafts** are *intentionally* in draft state, which means, they are **not open for review** yet (there is **no** `rfr` label) and solely serve as my public storage for ideas-in-progress in lieu of out-of-band media. The detail discussion you started regarding *details of the PR* was a bit too early IMHO (and surprised me, and actually your duplicate question in the PR confused me), as it is not even decided that we actually go with proposal A, so why discussing *details* of exactly *that* already (my conclusion was, you like to prepare it for the case it becomes the finalist of the mailing list discussion)? Maybe I misunderstood your intent, and you actually wanted to propose alternative (F), then sorry for me not seeing that in the first place.

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

PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439658000
PR Comment: https://git.openjdk.org/jdk/pull/21730#issuecomment-2439748858

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Rob Spoor)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
Message-ID: <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>

On Sat, 26 Oct 2024 15:48:11 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
> 
> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
> 
> To ensure quality...
> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.

src/java.base/share/classes/java/lang/CharSequence.java line 338:

> 336:      * @since 24
> 337:      */
> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {

Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1817880004

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
Message-ID: <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>

On Sat, 26 Oct 2024 16:19:32 GMT, Rob Spoor <duke at openjdk.org> wrote:

>> This Pull Request proposes an implementation for [JDK-8343110](https://bugs.openjdk.org/browse/JDK-8343110): Adding the new method `public void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` to the `CharSequence` interface, providing a **bulk-read** facility including a default implementation iterating over `charAt(int)`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `Reader.of(CharSequence).read(char[] cbuf, int off, int len)` to invoke `CharSequence.getChars(next, next + n, cbuf, off)` instead of utilizing pattern matching for switch. Also, this PR proposes to implement `CharBuffer.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)` as an alias for `CharBuffer.get(srcBegin, dst, dstBegin, srcEnd - srcBegin)`.
>> 
>> To ensure quality...
>> * ...the method signature and JavaDocs are adapted from `AbstractStringBuilder.getChars(...)`.
>> * ...this PR relies upon the existing tests for `Reader.of(CharSequence)`, as these provide sufficient coverage of all changes introduced by this PR.
>
> src/java.base/share/classes/java/lang/CharSequence.java line 338:
> 
>> 336:      * @since 24
>> 337:      */
>> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
> 
> Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?

While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1817891741

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Markus KARG)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
 <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
Message-ID: <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>

On Sat, 26 Oct 2024 17:09:29 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/CharSequence.java line 338:
>> 
>>> 336:      * @since 24
>>> 337:      */
>>> 338:     public default void getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin) {
>> 
>> Shouldn't the `getChars` methods of `String`, `AbstractStringBuilder`, `StringBuilder` and `StringBuffer` be marked with `@Override`?
>
> While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).

Fixed in `String` and `AbstractStringBuilder`. There is no `StringBuilder.getChars`. `StringBuffer.getChars` already has `@Override`, just as `CharBuffer.getChars`. Thanks for the tip! ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1947929157

From duke at openjdk.org  Sun Feb  9 18:41:34 2025
From: duke at openjdk.org (Rob Spoor)
Date: Sun, 9 Feb 2025 18:41:34 GMT
Subject: RFR: 8343110: Add getChars(int, int, char[],
 int) to CharSequence and CharBuffer
In-Reply-To: <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>
References: <wgGkTJdpTfITcwkkglmOqIS-zdJhHtMkqZ7D5Rqi7vw=.076da808-d87e-4938-a6dc-4387bad31b61@github.com>
 <hECkKj_ZjbRmBfhGGdWftHnBlcnVYkdm2bjonSJvsbE=.5d5c8608-d717-45e5-8363-4e20f682042a@github.com>
 <YBp_jIj8IpXOBPfVNeMciZnSXfy04XDnlsM5xgfPP3Q=.26bf5351-35a7-4c16-a55d-2387224db0d9@github.com>
 <E-2bpWjAIQJc6GyH4FfeOB7Tw9c2dKVgEqQbBl1W7ks=.30fdade5-6ab8-4a32-8fe8-df74f2b56612@github.com>
Message-ID: <leEZ0wNXF8qF0lEpNFyk3CoFhf2mJ6M3DKIoPLIc1zI=.43246c40-504b-4281-ae0d-57744d446383@github.com>

On Sat, 8 Feb 2025 18:56:00 GMT, Markus KARG <duke at openjdk.org> wrote:

>> While technically not being necessary, it is definitively a good idea. I will add it to the draft once we actually agreed that we really want to go with this particular signature (see the discussion with Chen).
>
> Fixed in `String` and `AbstractStringBuilder`. There is no `StringBuilder.getChars`. `StringBuffer.getChars` already has `@Override`, just as `CharBuffer.getChars`. Thanks for the tip! ?

You're welcome :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21730#discussion_r1948073040

From shade at openjdk.org  Mon Feb 10 09:31:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 10 Feb 2025 09:31:28 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <L-No84e66ZZFpxf_d3c2ePydWwzVN4-zSf3jY7Jj5GM=.d9dca630-dbe8-456a-8a2e-937bd49e09c8@github.com>
 <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com>
 <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
Message-ID: <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>

On Thu, 30 Jan 2025 16:25:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing.
>
> @AlanBateman I've not done any work on JDK-8305186.  There has also been discussion about making
> that function non-private or even public (though with concerns about specification difficulty) for use in
> places like this.
> 
> @shipilev I'm working on a reply, but it might be long-ish.  That outpacing issue for some tests is why this
> code wasn't switched away from jdk.internal.ref.Cleaner a long time ago.  I'm still looking at it, but I currently
> don't think the canary provides a reliable solution to that.

I would like to integrate this PR. How are you doing, @kimbarrett? Have you found any major holes in it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1948705265

From bpb at openjdk.org  Mon Feb 10 17:18:21 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 10 Feb 2025 17:18:21 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com>
Message-ID: <_zxZyGe0-1D_LWJyhrJqYu3e_RLBHJ0si_SRuptCkSE=.435a91e7-277b-4187-b804-692aba507dd2@github.com>

On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge
>  - Merge
>  - Merge
>  - 8337143: Minor makefile tweak
>  - 8337143: Clean up to address reviewer comments
>  - Merge
>  - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2648719746

From syan at openjdk.org  Tue Feb 11 02:49:49 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 02:49:49 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
Message-ID: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>

H all,

This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.

I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.

1. java/lang/management/ThreadMXBean/VirtualThreads.java#default

VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.

2. java/lang/Thread/virtual/stress/PinALot.java

PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".

3. java/lang/Thread/virtual/SynchronizedNative.java

Call System.loadLibrary("SynchronizedNative") at line 85.

4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java


- Why we need the '/native' keywork?

I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.

Change has been verified locally, test-fix, no risk.

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

Commit messages:
 - 8349689: Several virtual thread tests missing /native keyword

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

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

From alanb at openjdk.org  Tue Feb 11 07:29:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:29:09 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native VirtualThreads

Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950353219

From alanb at openjdk.org  Tue Feb 11 07:33:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 07:33:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

Can you check if these two needs to be updated too?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
test/jdk/java/lang/Thread/virtual/Starvation.java

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650016781

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <0bp5M6-iiZxngQJk5uRVX6h_-uMXYYG2zBOtqgQEQDo=.96dc6c54-59ae-42d3-8f8e-ed531e15c0a9@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/03e76ed3..7c030997

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

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

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

From syan at openjdk.org  Tue Feb 11 07:43:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 07:43:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v2]
In-Reply-To: <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Of1AGZzrUCxm87JHwlMt8-OXoqXw3OEV8qQta4dRxdw=.024f2266-368f-4bc5-9fa9-60929822bd31@github.com>
Message-ID: <mkh92dxM39AIrZDtRErygNzyJhmTC9kpS_zV0kJW954=.269d6d2d-fcbd-400e-b2e2-7adadf66dd14@github.com>

On Tue, 11 Feb 2025 07:26:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add --enable-native-access=ALL-UNNAMED for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java#default
>
> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native VirtualThreads
> 
> Can you add `--enable-native-access=ALL-UNNAMED` to this test while you are editing this line? It makes it more obvious that it invokes native code and also removes the warning at runtime.

Thanks. Argument `--enable-native-access=ALL-UNNAMED` has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950365978

From syan at openjdk.org  Tue Feb 11 08:38:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:38:48 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/7c030997..413ee6b1

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

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/23550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23550/head:pull/23550

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

From syan at openjdk.org  Tue Feb 11 08:47:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
In-Reply-To: <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <SUVzURn2ddC0NfegZpTP92cCAtb49hr_ehCTgc1uF7c=.10f321b0-e348-46e7-b5b9-65dd9abee38c@github.com>
Message-ID: <W3DxZL_gHfiu5vtMqDWnFGgWEU5LPV1odLtVXijdkJY=.d4252543-9bda-4e96-ab6b-2105c6547c03@github.com>

On Tue, 11 Feb 2025 07:30:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you check if these two needs to be updated too?
> 
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

These two tests also need `/native` keyword.

- Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java do not report test failed or error when missing load the native shared libary. So I add a check to make sure that the first virtual of this test run normally.

The original test output from jfr file shows below:


STARTED    ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'
Exception in thread "" java.lang.ExceptionInInitializerError
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    ... 2 more
Caused by: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:350)
    at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:335)
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:130)
    ... 3 more
Exception in thread "" java.lang.NoClassDefFoundError: Could not initialize class jdk.test.lib.thread.VThreadPinner
    at ThreadPollOnYield.lambda$testThreadYieldPolls$2(ThreadPollOnYield.java:69)
    at java.base/java.lang.VirtualThread.run(VirtualThread.java:466)
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.RuntimeException: java.lang.IllegalArgumentException: Cannot open library: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib/libVThreadPinner.so [in thread "ForkJoinPool-1-worker-1"]
    at jdk.test.lib.thread.VThreadPinner.invoker(VThreadPinner.java:135)
    at jdk.test.lib.thread.VThreadPinner.<clinit>(VThreadPinner.java:50)
    at ThreadPollOnYield.lambda$testThreadYieldPolls$0(ThreadPollOnYield.java:59)
    ... 1 more
SUCCESSFUL ThreadPollOnYield::testThreadYieldPolls 'testThreadYieldPolls()'



- Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add `timeout=200` also.


elapsed time (seconds): 121.41

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650141187

From alanb at openjdk.org  Tue Feb 11 08:47:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:47:13 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
Message-ID: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>

On Tue, 11 Feb 2025 08:38:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 28:

> 26:  * @library /test/lib
> 27:  * @bug 8345294
> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000

Did you mean to add /timeout=200 to this test?

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:

> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
> 38:  * @library /test/lib
> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield

Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:

> 67:         if (flag != true) {
> 68:             throw new RuntimeException("flag = " + flag);
> 69:         }

What are these other changes about?

test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:

> 28:  * @modules java.base/java.lang:+open java.management
> 29:  * @library /test/lib
> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads

Can you check if the end copyright date needs to be updated on this one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950436579
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439893
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950438562
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440627

From syan at openjdk.org  Tue Feb 11 08:47:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:47:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>

On Tue, 11 Feb 2025 08:41:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 28:
> 
>> 26:  * @library /test/lib
>> 27:  * @bug 8345294
>> 28:  * @run main/othervm/timeout=200/native --enable-native-access=ALL-UNNAMED Starvation 100000
> 
> Did you mean to add /timeout=200 to this test?

Test test/jdk/java/lang/Thread/virtual/Starvation.java execute over 120 seconds on my local environment. So I add timeout=200 also.

> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
> 
>> 67:         if (flag != true) {
>> 68:             throw new RuntimeException("flag = " + flag);
>> 69:         }
> 
> What are these other changes about?

Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950440123
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950439898

From syan at openjdk.org  Tue Feb 11 08:53:46 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:46 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v4]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XL5_3IfJOXgAxPLi6mkQbGahdqhlwyh99KdOUZVjyP0=.aefddd7b-fbd1-477a-ab42-f0280d42b745@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  update copyright year for test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java; Split @run line for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/413ee6b1..07f34357

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

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

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

From syan at openjdk.org  Tue Feb 11 08:53:47 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 08:53:47 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
Message-ID: <PVDVRTf-xeGDKnWVzkghJizkZRxWPIIagWHXvnsUc3c=.fdac3bf4-436c-4f80-ba14-2fc27f38d8c2@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java test/jdk/java/lang/Thread/virtual/Starvation.java
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 39:
> 
>> 37:  * @requires vm.continuations & vm.compMode != "Xcomp"
>> 38:  * @library /test/lib
>> 39:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED -Xcomp -XX:-TieredCompilation -XX:CompileCommand=inline,*::yield* -XX:CompileCommand=inline,*::*Yield ThreadPollOnYield
> 
> Would you mind splitting this line (jtreg is okay with that) as it's nearly 190 chars now so getting too long.

Okey, this line has been split two lines.

> test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java line 30:
> 
>> 28:  * @modules java.base/java.lang:+open java.management
>> 29:  * @library /test/lib
>> 30:  * @run junit/othervm/native --enable-native-access=ALL-UNNAMED VirtualThreads
> 
> Can you check if the end copyright date needs to be updated on this one.

Sorry, the copyright date has been updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950447560
PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950448055

From alanb at openjdk.org  Tue Feb 11 08:56:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 08:56:11 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
Message-ID: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>

On Tue, 11 Feb 2025 08:44:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java line 69:
>> 
>>> 67:         if (flag != true) {
>>> 68:             throw new RuntimeException("flag = " + flag);
>>> 69:         }
>> 
>> What are these other changes about?
>
> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.

Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950452441

From syan at openjdk.org  Tue Feb 11 09:03:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:24 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

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

  Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23550/files
  - new: https://git.openjdk.org/jdk/pull/23550/files/07f34357..912c1ab3

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

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

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

From syan at openjdk.org  Tue Feb 11 09:03:25 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:03:25 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
Message-ID: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>

On Tue, 11 Feb 2025 08:53:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reason description as https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.
>
> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.

Okey, the additional check has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950462081

From syan at openjdk.org  Tue Feb 11 09:10:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:10:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v3]
In-Reply-To: <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <Uc2Cy95UC65Jkl-Af68f0eIx9ytRx9-NqAdEfd0FhCQ=.f94fee6a-eeba-4717-911c-8f818cc11789@github.com>
 <jwU2okc4ozif3U2223CL8YYgLde-Kxfjg0B1hLmtaiA=.08b6f350-6794-4b90-8398-a0fc52828c4a@github.com>
 <Jg255u_FI4na-eNeyitbIYqOUfZbH0kDYxmt-jutvoA=.fafaa064-7908-4520-9b8b-80d81fe237e9@github.com>
 <jNjxb0ICFVP8dva3FROLJGVqYY_gNiLiysF7Syq-Nz4=.51b9716c-f5ae-4092-9cef-cc209a2b6f62@github.com>
 <gYHa8V4K2jhEtds5JwLG6s4zNb_awl-2nXn0KTq8Kvk=.a501a0bb-fb73-4d07-9666-c53a96004899@github.com>
Message-ID: <jUNt_xes1UYoItHwJqUDnLoe_8ni56CMXGxvKmtRgcM=.432e03ea-b648-4647-9dfe-918a44c18ef9@github.com>

On Tue, 11 Feb 2025 09:00:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Can you remove this change from the PR as it this is a separate discussion? My guess is that in your environment the Thread.yield is somehow taking more than 5 seconds, is that right? In that case, we can modify the test to use a latch to ensure that it loops at least once. Anyway, separate issue, we shouldn't include it in this PR.
>
> Okey, the additional check has been removed.

I have created a separate [issue](https://bugs.openjdk.org/browse/JDK-8349787) to record that. I will investigate later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1950471694

From alanb at openjdk.org  Tue Feb 11 09:24:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 09:24:10 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <-WVSOZWZXjlAhICbHjfuu-QEAlpqx_Pmyy4EIvfdwQk=.dcac8e8d-5662-4dda-87de-8931e86c3960@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

912c1ab3 looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2608124096

From syan at openjdk.org  Tue Feb 11 09:30:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Feb 2025 09:30:14 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <UgO_pPmUbbGUSzuY8XmBTgScyYkptyf45DKrKgRuOcY=.4d243896-996c-481e-b9aa-6a1810c4aa11@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

> [912c1ab](https://github.com/openjdk/jdk/commit/912c1ab384ffb82e36e46cbf2236b42d4321bc27) looks okay.

@AlanBateman Thanks for the patience suggest and review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2650245614

From mkartashev at openjdk.org  Tue Feb 11 10:33:19 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 11 Feb 2025 10:33:19 GMT
Subject: RFR: 8349812: Unexpected exception opening empty path name with WRITE, 
 CREATE_NEW
Message-ID: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>

`UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.

The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.

Tested by running `java/nio` tests on Linux.

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

Commit messages:
 - 8349812: Unexpected exception opening empty path name with WRITE, CREATE_NEW

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

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

From alanb at openjdk.org  Tue Feb 11 11:01:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 11:01:10 GMT
Subject: RFR: 8349812: Unexpected exception opening empty path name with
 WRITE, CREATE_NEW
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <c0f_m9W8TqVnevwyiJ1Utvp2eNGh7u3CdwldXkhcye8=.39f33df1-d3f7-4fdd-8ce5-8e1389c641e6@github.com>

On Tue, 11 Feb 2025 10:28:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

This seems to be an oversight from when this code was introduced in JDK 7. 

We use a convention in this area for the title on JBS issues so I've had to rename the JBS issue. Can you rename the PR to align with this. We will likely need to add a lot more tests to ensure that all methods/options are exercised with an empty Path.

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

PR Comment: https://git.openjdk.org/jdk/pull/23560#issuecomment-2650461762

From mkartashev at openjdk.org  Tue Feb 11 11:49:10 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 11 Feb 2025 11:49:10 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <c0f_m9W8TqVnevwyiJ1Utvp2eNGh7u3CdwldXkhcye8=.39f33df1-d3f7-4fdd-8ce5-8e1389c641e6@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <c0f_m9W8TqVnevwyiJ1Utvp2eNGh7u3CdwldXkhcye8=.39f33df1-d3f7-4fdd-8ce5-8e1389c641e6@github.com>
Message-ID: <EgU8VR87KgUTzSBetENaUG8NQ84nCGQzVy0z7ZQH7FQ=.2ed640a2-550f-434a-bbab-c54bc2b8ac94@github.com>

On Tue, 11 Feb 2025 10:58:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We use a convention in this area for the title on JBS issues so I've had to rename the JBS issue. Can you rename the PR to align with this

Of course. Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/23560#issuecomment-2650571638

From jpai at openjdk.org  Tue Feb 11 12:11:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Feb 2025 12:11:15 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <ZdmK2MNjcV07VgCokuqAUnjSs2YEGljSlQzxnGv5Auc=.8fef4aa4-3726-4010-8728-2f79d96a05ff@github.com>

On Tue, 11 Feb 2025 10:28:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

test/jdk/java/nio/file/Files/SBC.java line 66:

> 64:             unsupportedOptions(dir);
> 65:             nullTests(dir);
> 66:             emptyPathTest();

I think the `@bug` of this test would also have to be updated to include `8349812`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1950728147

From bpb at openjdk.org  Tue Feb 11 16:06:15 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Feb 2025 16:06:15 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <ZdmK2MNjcV07VgCokuqAUnjSs2YEGljSlQzxnGv5Auc=.8fef4aa4-3726-4010-8728-2f79d96a05ff@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <ZdmK2MNjcV07VgCokuqAUnjSs2YEGljSlQzxnGv5Auc=.8fef4aa4-3726-4010-8728-2f79d96a05ff@github.com>
Message-ID: <rPIwg8j5dDTQ1ThjnxhGAWPq5US8vwH1GNMQaXZC16s=.8f5b6ae4-1684-4da3-bcbf-5771bdf87df0@github.com>

On Tue, 11 Feb 2025 12:08:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I think the `@bug` of this test would also have to be updated to include `8349812`.

Also, the copyright year update is missing in both files. I'll approve this once those three changes are made. Whether other tests for empty paths are needed can be evaluated separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1951133435

From bpb at openjdk.org  Tue Feb 11 19:35:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Feb 2025 19:35:12 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <SIE3tBHnbdlWmbd6QebiXK9-BpFqLi4QaDFDho0DHl8=.8de54c0f-35e7-4df6-b309-2f253d1b95c4@github.com>

On Tue, 11 Feb 2025 10:28:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java line 198:

> 196:             // create flags
> 197:             if (flags.createNew) {
> 198:                 byte[] pathForSysCall = path.getByteArrayForSysCalls();

Does this need to be done at line 240 as well?

fd = openat(dfd, path.asByteArray(), oflags, mode);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1951477287

From alanb at openjdk.org  Tue Feb 11 20:52:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 11 Feb 2025 20:52:10 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <SIE3tBHnbdlWmbd6QebiXK9-BpFqLi4QaDFDho0DHl8=.8de54c0f-35e7-4df6-b309-2f253d1b95c4@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <SIE3tBHnbdlWmbd6QebiXK9-BpFqLi4QaDFDho0DHl8=.8de54c0f-35e7-4df6-b309-2f253d1b95c4@github.com>
Message-ID: <1kOJDYG2tfkJSpz2NIqnQEv8KCsbL5nw7NzAWpuDJAo=.7e19b139-d103-4a8a-93cd-a6442e8c64bc@github.com>

On Tue, 11 Feb 2025 19:32:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
>> 
>> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
>> 
>> Tested by running `java/nio` tests on Linux.
>
> src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java line 198:
> 
>> 196:             // create flags
>> 197:             if (flags.createNew) {
>> 198:                 byte[] pathForSysCall = path.getByteArrayForSysCalls();
> 
> Does this need to be done at line 240 as well?
> 
> fd = openat(dfd, path.asByteArray(), oflags, mode);

When *at functions the second parameter is relative to the open directory so need to be careful, need to make sure there are good tests before changing anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1951582355

From bpb at openjdk.org  Tue Feb 11 21:48:11 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 11 Feb 2025 21:48:11 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception
In-Reply-To: <1kOJDYG2tfkJSpz2NIqnQEv8KCsbL5nw7NzAWpuDJAo=.7e19b139-d103-4a8a-93cd-a6442e8c64bc@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <SIE3tBHnbdlWmbd6QebiXK9-BpFqLi4QaDFDho0DHl8=.8de54c0f-35e7-4df6-b309-2f253d1b95c4@github.com>
 <1kOJDYG2tfkJSpz2NIqnQEv8KCsbL5nw7NzAWpuDJAo=.7e19b139-d103-4a8a-93cd-a6442e8c64bc@github.com>
Message-ID: <2QSNWWAYq0CHsJ3HfyFct8qwjyAYzsrkwE9A_r9t3wE=.e4bd0fc8-ab3f-4400-bd37-470fff45d3fa@github.com>

On Tue, 11 Feb 2025 20:49:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java line 198:
>> 
>>> 196:             // create flags
>>> 197:             if (flags.createNew) {
>>> 198:                 byte[] pathForSysCall = path.getByteArrayForSysCalls();
>> 
>> Does this need to be done at line 240 as well?
>> 
>> fd = openat(dfd, path.asByteArray(), oflags, mode);
>
> With *at functions the second parameter is relative to the open directory so need to be careful, need to make sure there are good tests before changing anything. In other words, something else must be broken if *at functions are being called with a getByteArrayForSysCalls as the second parameter.

> When *at functions the second parameter is relative to the open directory [...]

I tested this for `fstatat` by obtaining the attributes of a file via a `SecureDirectoryStream` and it made no difference, but if `UnixFileSystem.needToResolveAgainstDefaultDirectory()` returned `true`, it seems likely it would introduce a problem. Hence I suggest ignoring my comment above and leaving line 240 as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1951653832

From lmesnik at openjdk.org  Wed Feb 12 00:30:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Feb 2025 00:30:12 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <miP5yG1cxruk-95cFJS12OB98XAg0nSm_xkci79tbQ4=.921bf560-093f-4cb8-bcfd-eb24b0ff4049@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2610467761

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <db73BhWt2Xgz_zGic_5SxAW-ho2D-yaSerK-v64lfNs=.30b138e6-20c2-4d5e-a738-cdb2c8ca551b@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23550#issuecomment-2652545506

From syan at openjdk.org  Wed Feb 12 03:03:26 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 03:03:26 GMT
Subject: Integrated: 8349689: Several virtual thread tests missing /native
 keyword
In-Reply-To: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
Message-ID: <XGK3Deje9V8dDObSEdwBq5uveDcwruowG_lPj9U8rvY=.c361a005-650c-4bab-ad71-a1f87159d360@github.com>

On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> H all,
> 
> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
> 
> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
> 
> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
> 
> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
> 
> 2. java/lang/Thread/virtual/stress/PinALot.java
> 
> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
> 
> 3. java/lang/Thread/virtual/SynchronizedNative.java
> 
> Call System.loadLibrary("SynchronizedNative") at line 85.
> 
> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
> 
> 
> - Why we need the '/native' keywork?
> 
> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
> 
> Change has been verified locally, test-fix, no risk.

This pull request has now been integrated.

Changeset: 88b4a906
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88b4a906d2c520ce6a7b21adc5e709067e520cdd
Stats:     55 lines in 12 files changed: 1 ins; 0 del; 54 mod

8349689: Several virtual thread tests missing /native keyword

Reviewed-by: alanb, lmesnik

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

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

From dholmes at openjdk.org  Wed Feb 12 03:46:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 12 Feb 2025 03:46:16 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

test/jdk/java/lang/Thread/virtual/Starvation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.

You missed the comma after 2025 here. This is now causing failures in our CI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951933716

From syan at openjdk.org  Wed Feb 12 04:38:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 12 Feb 2025 04:38:19 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
 <sJ_UAcGbIL7_HNi9UjRplJKfjCcO2Q6NpYxVoLTbOgw=.04ab048c-254b-432e-b447-061a39b28c6a@github.com>
Message-ID: <iow9jDZFLb3hH5Im4vQFk-lnBX6c4HZl93SMpWM7GTg=.4e95a434-c0d2-4a48-9c5c-d29b319d6cd4@github.com>

On Wed, 12 Feb 2025 03:43:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
>
> test/jdk/java/lang/Thread/virtual/Starvation.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2025 Oracle and/or its affiliates. All rights reserved.
> 
> You missed the comma after 2025 here. This is now causing failures in our CI.

Sorry, I create a new issue [JDK-8349876](https://bugs.openjdk.org/browse/JDK-8349876) for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23550#discussion_r1951963891

From alanb at openjdk.org  Wed Feb 12 07:03:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 07:03:09 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

@bplb You may have to double check that this works for us.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2652824313

From mkartashev at openjdk.org  Wed Feb 12 08:43:47 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 12 Feb 2025 08:43:47 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Updated the copyright year and added the bugid to the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23560/files
  - new: https://git.openjdk.org/jdk/pull/23560/files/0a1a7ead..d0d42a4d

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

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

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

From mkartashev at openjdk.org  Wed Feb 12 08:43:47 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 12 Feb 2025 08:43:47 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <rPIwg8j5dDTQ1ThjnxhGAWPq5US8vwH1GNMQaXZC16s=.8f5b6ae4-1684-4da3-bcbf-5771bdf87df0@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <ZdmK2MNjcV07VgCokuqAUnjSs2YEGljSlQzxnGv5Auc=.8fef4aa4-3726-4010-8728-2f79d96a05ff@github.com>
 <rPIwg8j5dDTQ1ThjnxhGAWPq5US8vwH1GNMQaXZC16s=.8f5b6ae4-1684-4da3-bcbf-5771bdf87df0@github.com>
Message-ID: <1BklrjeQ62KHOj--AcZ9YP2_r5enqYiFE_4r6cdY6eE=.28e4afea-be35-48f0-96ef-e288823d37d5@github.com>

On Tue, 11 Feb 2025 16:03:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/Files/SBC.java line 66:
>> 
>>> 64:             unsupportedOptions(dir);
>>> 65:             nullTests(dir);
>>> 66:             emptyPathTest();
>> 
>> I think the `@bug` of this test would also have to be updated to include `8349812`.
>
>> I think the `@bug` of this test would also have to be updated to include `8349812`.
> 
> Also, the copyright year update is missing in both files. I'll approve this once those three changes are made. Whether other tests for empty paths are needed can be evaluated separately.

Addressed both concerns with the new commit, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1952208147

From alanb at openjdk.org  Wed Feb 12 09:27:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 12 Feb 2025 09:27:10 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>
Message-ID: <fiXdamgMv-qSTy8FbuyDh-6LsoA2NhBPiHj9P8sln18=.2803350d-39eb-41e3-b576-cae22dca4ee2@github.com>

On Wed, 12 Feb 2025 08:43:47 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
>> 
>> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
>> 
>> Tested by running `java/nio` tests on Linux.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated the copyright year and added the bugid to the test

test/jdk/java/nio/file/Files/SBC.java line 433:

> 431:             Files.newByteChannel(Path.of(""), opts);
> 432:             throw new RuntimeException("FileAlreadyExistsException expected");
> 433:         } catch (FileAlreadyExistsException x) { }

While WRITE + CREATE_NEW are the options to tickle the bug, I think emptyPathTest should be expanded to test over combinations of open options. There are several code paths with options such as O_NOFOLLOW and DELETE_ON_CLOSE that will also need to be tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1952274932

From mkartashev at openjdk.org  Wed Feb 12 10:13:27 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 12 Feb 2025 10:13:27 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v3]
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Extended the test for empty path name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23560/files
  - new: https://git.openjdk.org/jdk/pull/23560/files/d0d42a4d..c415adae

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

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

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

From mkartashev at openjdk.org  Wed Feb 12 10:13:27 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Wed, 12 Feb 2025 10:13:27 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <fiXdamgMv-qSTy8FbuyDh-6LsoA2NhBPiHj9P8sln18=.2803350d-39eb-41e3-b576-cae22dca4ee2@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>
 <fiXdamgMv-qSTy8FbuyDh-6LsoA2NhBPiHj9P8sln18=.2803350d-39eb-41e3-b576-cae22dca4ee2@github.com>
Message-ID: <GwuYkycoMfkHO82bHy0v8wrCPBpsgn47yx9hl3sfGEs=.56ab5761-d4cd-4604-9c38-f65e096309cf@github.com>

On Wed, 12 Feb 2025 09:24:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated the copyright year and added the bugid to the test
>
> test/jdk/java/nio/file/Files/SBC.java line 433:
> 
>> 431:             Files.newByteChannel(Path.of(""), opts);
>> 432:             throw new RuntimeException("FileAlreadyExistsException expected");
>> 433:         } catch (FileAlreadyExistsException x) { }
> 
> While WRITE + CREATE_NEW are the options to tickle the bug, I think emptyPathTest should be expanded to test over combinations of open options. There are several code paths with options such as O_NOFOLLOW and DELETE_ON_CLOSE that will also need to be tested.

I extended the test a bit. Have a look, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1952353375

From jiangli at openjdk.org  Wed Feb 12 17:29:11 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 12 Feb 2025 17:29:11 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
Message-ID: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>

On Wed, 12 Feb 2025 07:00:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @bplb You may have to double check that this works for us.

Thanks!

@bplb, please let me know your internal testing result. If there's no additional internal test source changes in those native libraries, I think testing should not run into any issue. These tests native code only uses standard JNI APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2654396167

From bpb at openjdk.org  Wed Feb 12 17:32:13 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 17:32:13 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
Message-ID: <4qjjVJr1gRimdsj5vZh4j8Aa3MaYnWdAKo9u4oHrdvI=.afd91988-46a1-4f25-bda9-c3090f944341@github.com>

On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> please let me know your internal testing result.

Sure, of course.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2654400869

From bpb at openjdk.org  Wed Feb 12 21:54:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 21:54:26 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <GwuYkycoMfkHO82bHy0v8wrCPBpsgn47yx9hl3sfGEs=.56ab5761-d4cd-4604-9c38-f65e096309cf@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>
 <fiXdamgMv-qSTy8FbuyDh-6LsoA2NhBPiHj9P8sln18=.2803350d-39eb-41e3-b576-cae22dca4ee2@github.com>
 <GwuYkycoMfkHO82bHy0v8wrCPBpsgn47yx9hl3sfGEs=.56ab5761-d4cd-4604-9c38-f65e096309cf@github.com>
Message-ID: <2wS9n6t2i2MigufHl9GmPA1_USdEYL0D6syXm6mwsi0=.fbe76bf0-afbc-4cf3-bdc3-fce046873070@github.com>

On Wed, 12 Feb 2025 10:10:51 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> test/jdk/java/nio/file/Files/SBC.java line 433:
>> 
>>> 431:             Files.newByteChannel(Path.of(""), opts);
>>> 432:             throw new RuntimeException("FileAlreadyExistsException expected");
>>> 433:         } catch (FileAlreadyExistsException x) { }
>> 
>> While WRITE + CREATE_NEW are the options to tickle the bug, I think emptyPathTest should be expanded to test over combinations of open options. There are several code paths with options such as O_NOFOLLOW and DELETE_ON_CLOSE that will also need to be tested.
>
> I extended the test a bit. Have a look, please.

There is now a failure on Windows:

java.nio.file.AccessDeniedException: 
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
	at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
	at java.base/java.nio.file.Files.newByteChannel(Files.java:399)
	at SBC.emptyPathTest(SBC.java:444)
	at SBC.main(SBC.java:66)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1953450072

From bpb at openjdk.org  Wed Feb 12 21:54:27 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 21:54:27 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v3]
In-Reply-To: <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>
Message-ID: <FA9y3xz5H1U1dHiMSriGxe760KTu3cauNBiW37cojm0=.72babf57-c564-4c34-bd5d-5c7694e83765@github.com>

On Wed, 12 Feb 2025 10:13:27 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
>> 
>> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
>> 
>> Tested by running `java/nio` tests on Linux.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extended the test for empty path name

test/jdk/java/nio/file/Files/SBC.java line 444:

> 442:         } catch (FileSystemException x) { }
> 443: 
> 444:         try (var channel = Files.newByteChannel(Path.of(""), READ, LinkOption.NOFOLLOW_LINKS)) {

This sub-test fails on Windows with a `java.nio.file.AccessDeniedException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1953452170

From bpb at openjdk.org  Wed Feb 12 23:40:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 12 Feb 2025 23:40:12 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
Message-ID: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>

On Wed, 12 Feb 2025 17:26:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I think testing should not run into any issue

I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests

java/nio/jni/NewDirectByteBuffer.java
java/nio/channels/FileChannel/directio
java/nio/channels/spi/SelectorProvider/inheritedChannel

which the proposed change specifically would affect.

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2655080371

From jiangli at openjdk.org  Thu Feb 13 00:21:10 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 00:21:10 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
 <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
Message-ID: <lVr7e8WnH5R7T2iSUWJ-bK7lUxL4YNbeF9GWVT3a9KQ=.875b5023-db02-43d9-aa15-5de9f6e848f3@github.com>

On Wed, 12 Feb 2025 23:37:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I think testing should not run into any issue
> 
> I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests
> 
> ```
> java/nio/jni/NewDirectByteBuffer.java
> java/nio/channels/FileChannel/directio
> java/nio/channels/spi/SelectorProvider/inheritedChannel
> ```
> 
> which the proposed change specifically would affect.

Thank you, @bplb!

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2655140100

From mkartashev at openjdk.org  Thu Feb 13 10:24:11 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Feb 2025 10:24:11 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v2]
In-Reply-To: <2wS9n6t2i2MigufHl9GmPA1_USdEYL0D6syXm6mwsi0=.fbe76bf0-afbc-4cf3-bdc3-fce046873070@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <_2uIlAdjWq1qnG0tgHhh-FU-sSb8oYUf4_E8zP65m0M=.4efaf19b-fb6a-433b-90ae-3e903729abaa@github.com>
 <fiXdamgMv-qSTy8FbuyDh-6LsoA2NhBPiHj9P8sln18=.2803350d-39eb-41e3-b576-cae22dca4ee2@github.com>
 <GwuYkycoMfkHO82bHy0v8wrCPBpsgn47yx9hl3sfGEs=.56ab5761-d4cd-4604-9c38-f65e096309cf@github.com>
 <2wS9n6t2i2MigufHl9GmPA1_USdEYL0D6syXm6mwsi0=.fbe76bf0-afbc-4cf3-bdc3-fce046873070@github.com>
Message-ID: <8qVIWrutAEq2gbGEiDuB-rPdptafRTPcO2DzTGIE9gM=.3980ee5d-c28b-409a-8c06-4e65ae03daf4@github.com>

On Wed, 12 Feb 2025 21:50:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I extended the test a bit. Have a look, please.
>
> There is now a failure on Windows:
> 
> java.nio.file.AccessDeniedException: 
> 	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> 	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> 	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
> 	at java.base/sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:231)
> 	at java.base/java.nio.file.Files.newByteChannel(Files.java:357)
> 	at java.base/java.nio.file.Files.newByteChannel(Files.java:399)
> 	at SBC.emptyPathTest(SBC.java:444)
> 	at SBC.main(SBC.java:66)

Indeed, on Windows the WinAPI function used to open a file (`CreateFileW`) will return `ERROR_ACCESS_DENIED` when used on a directory _without_ a special flag (`FILE_FLAG_BACKUP_SEMANTICS`). This flag is not specified in this particular code path. I will make the necessary changes to the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1954227606

From mkartashev at openjdk.org  Thu Feb 13 10:37:44 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Feb 2025 10:37:44 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v4]
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <sWpwSEm762dNGRxsjgzKJDJo-qTAQ2SuQhO2yOK1sKo=.1f24cf97-2f48-430e-ae59-6eb4a16f147c@github.com>

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the test to pass on Windows also

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23560/files
  - new: https://git.openjdk.org/jdk/pull/23560/files/c415adae..fe5c10b9

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

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

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

From mkartashev at openjdk.org  Thu Feb 13 10:46:11 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 13 Feb 2025 10:46:11 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v3]
In-Reply-To: <FA9y3xz5H1U1dHiMSriGxe760KTu3cauNBiW37cojm0=.72babf57-c564-4c34-bd5d-5c7694e83765@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>
 <FA9y3xz5H1U1dHiMSriGxe760KTu3cauNBiW37cojm0=.72babf57-c564-4c34-bd5d-5c7694e83765@github.com>
Message-ID: <NAyTxl170WHnTa-9JNisyBo_hj7c9adjnGqwaPvT_P0=.c10ec085-b138-4a47-bbe7-a33ed043f9d9@github.com>

On Wed, 12 Feb 2025 21:52:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extended the test for empty path name
>
> test/jdk/java/nio/file/Files/SBC.java line 444:
> 
>> 442:         } catch (FileSystemException x) { }
>> 443: 
>> 444:         try (var channel = Files.newByteChannel(Path.of(""), READ, LinkOption.NOFOLLOW_LINKS)) {
> 
> This sub-test fails on Windows with a `java.nio.file.AccessDeniedException`.

Should be fixed now. I also ran adjacent tests (`java/nio/file`) on Windows and Linux.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1954261612

From bpb at openjdk.org  Thu Feb 13 16:46:12 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 16:46:12 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v3]
In-Reply-To: <NAyTxl170WHnTa-9JNisyBo_hj7c9adjnGqwaPvT_P0=.c10ec085-b138-4a47-bbe7-a33ed043f9d9@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>
 <FA9y3xz5H1U1dHiMSriGxe760KTu3cauNBiW37cojm0=.72babf57-c564-4c34-bd5d-5c7694e83765@github.com>
 <NAyTxl170WHnTa-9JNisyBo_hj7c9adjnGqwaPvT_P0=.c10ec085-b138-4a47-bbe7-a33ed043f9d9@github.com>
Message-ID: <-pDsOUr5ZMHITgcZdSGeFdSXBi1QWbuBp4Lej995_S8=.ed43d04b-1005-4050-87f5-d079ff8dc322@github.com>

On Thu, 13 Feb 2025 10:43:18 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> I also ran adjacent tests (`java/nio/file`) on Windows and Linux.

I am running corroborative tests on the three usual OSes now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1954860747

From bpb at openjdk.org  Thu Feb 13 17:57:09 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 17:57:09 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v4]
In-Reply-To: <sWpwSEm762dNGRxsjgzKJDJo-qTAQ2SuQhO2yOK1sKo=.1f24cf97-2f48-430e-ae59-6eb4a16f147c@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <sWpwSEm762dNGRxsjgzKJDJo-qTAQ2SuQhO2yOK1sKo=.1f24cf97-2f48-430e-ae59-6eb4a16f147c@github.com>
Message-ID: <jfjr5IaW-RXVcLzzicJsL0zhHRJU6mg9-OB4cKAzm2k=.3719e302-96bb-4562-9da2-56315c12bf22@github.com>

On Thu, 13 Feb 2025 10:37:44 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
>> 
>> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
>> 
>> Tested by running `java/nio` tests on Linux.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the test to pass on Windows also

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23560#pullrequestreview-2615829821

From bpb at openjdk.org  Thu Feb 13 17:57:10 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 17:57:10 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v3]
In-Reply-To: <-pDsOUr5ZMHITgcZdSGeFdSXBi1QWbuBp4Lej995_S8=.ed43d04b-1005-4050-87f5-d079ff8dc322@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <FskuN35gIZbDfunkwqYv2cjGLfTPgFpSBzNl3jMgQi8=.95abf593-2163-4102-92ae-e8d41b774247@github.com>
 <FA9y3xz5H1U1dHiMSriGxe760KTu3cauNBiW37cojm0=.72babf57-c564-4c34-bd5d-5c7694e83765@github.com>
 <NAyTxl170WHnTa-9JNisyBo_hj7c9adjnGqwaPvT_P0=.c10ec085-b138-4a47-bbe7-a33ed043f9d9@github.com>
 <-pDsOUr5ZMHITgcZdSGeFdSXBi1QWbuBp4Lej995_S8=.ed43d04b-1005-4050-87f5-d079ff8dc322@github.com>
Message-ID: <BPichRllsVZIp4OBvtg8E_3jPtr4eSXd8mDLddNJEK0=.666392a1-9c81-42e7-b033-43c5a029b96a@github.com>

On Thu, 13 Feb 2025 16:43:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Should be fixed now. I also ran adjacent tests (`java/nio/file`) on Windows and Linux.
>
>> I also ran adjacent tests (`java/nio/file`) on Windows and Linux.
> 
> I am running corroborative tests on the three usual OSes now.

My tests passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23560#discussion_r1954970557

From bpb at openjdk.org  Thu Feb 13 17:58:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 13 Feb 2025 17:58:17 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <1XiLaYYO6j9Gb_iLTk0t8shVf7wg8f1NBDUiC7oYny4=.a89e5258-edc9-421a-ac50-dbc9240ff456@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23575#pullrequestreview-2615832041

From jiangli at openjdk.org  Thu Feb 13 19:11:23 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 19:11:23 GMT
Subject: RFR: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
 <UqAW8qRvV_36KXIzmh_6wCA2sR7shZDsbUZgqG-McIE=.fbbf4fc5-b199-413a-a7d3-0e2876de02aa@github.com>
 <BWvo0VPmdhQTOLu2m1UiUzda7qw-RLi-OUbCs8m9m2U=.8bd3c7de-a19c-406f-b8dd-35b2e24f7c6b@github.com>
 <QwipYtvtCn1hI1NZ8WvqZr463MOgy0aGfJrxw1OxFPs=.f07cf136-f7c1-4c70-9298-9da5dec0dc82@github.com>
Message-ID: <l9H7HMOlzPnZLp1-b_BgTJCBh0iYyfNSZ_IUEmPtWRA=.31aff524-c503-40f4-8006-f8b6dcb1bed6@github.com>

On Wed, 12 Feb 2025 23:37:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> @bplb You may have to double check that this works for us.
>> 
>> Thanks!
>> 
>> @bplb, please let me know your internal testing result. If there's no additional internal test source changes in those native libraries, I think testing should not run into any issue. These tests native code only uses standard JNI APIs.
>
>> I think testing should not run into any issue
> 
> I did not find any problem for the tests in the [jdk_nio](https://github.com/openjdk/jdk/blob/55097dd4cbb5d691c12cb0247d66dce593759d59/test/jdk/TEST.groups#L206) group on Linux, macOS, or Windows. This test group includes in particular these tests
> 
> java/nio/jni/NewDirectByteBuffer.java
> java/nio/channels/FileChannel/directio
> java/nio/channels/spi/SelectorProvider/inheritedChannel
> 
> which the proposed change specifically would affect.

@bplb Thanks again for the review and running internal testing!

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

PR Comment: https://git.openjdk.org/jdk/pull/23575#issuecomment-2657488985

From jiangli at openjdk.org  Thu Feb 13 19:11:24 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Feb 2025 19:11:24 GMT
Subject: Integrated: 8349868: Remove unneeded libjava shared library dependency
 from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel
In-Reply-To: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
References: <MOCKwqcJbpMbDQZpRyImw94OgkDkueOAVVaKALeYDSY=.11dad99c-a540-459f-a74a-24e2e7fc3a39@github.com>
Message-ID: <c2d8nrcps491E74Q1DUqGJ_x8H8xoYEjTT-_mNi3z4o=.6fc34bfd-8600-4d13-805c-5eb91315ebf6@github.com>

On Wed, 12 Feb 2025 03:00:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that removes libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel. Thanks

This pull request has now been integrated.

Changeset: 2eac490b
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2eac490bd22f5488a60e59f93ce54d4babf33c23
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8349868: Remove unneeded libjava shared library dependency from jtreg test libNewDirectByteBuffer, libDirectIO and libInheritedChannel

Reviewed-by: bpb

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

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

From kbarrett at openjdk.org  Fri Feb 14 06:29:25 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 14 Feb 2025 06:29:25 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <L-No84e66ZZFpxf_d3c2ePydWwzVN4-zSf3jY7Jj5GM=.d9dca630-dbe8-456a-8a2e-937bd49e09c8@github.com>
 <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com>
 <Qg6LRxXXXTeW4eITWQ_06w1nfpQBrf7irmF_WLsx9Kg=.07000623-4c26-4440-9a27-3c2e804ec14c@github.com>
 <8Ci27Bl509_2RKPjvYfv2QOdZ7UzP9dNOoTZQIpcrgc=.01e9fbb8-a292-4ad8-97eb-fd9e6e65ffff@github.com>
Message-ID: <UoSAIMWk_0iNywNjPb8YBEQ8VumG_spdeVN0QIfVk8U=.30a59433-51df-4dc5-b74e-46f2512f1c87@github.com>

On Mon, 10 Feb 2025 09:28:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @AlanBateman I've not done any work on JDK-8305186.  There has also been discussion about making
>> that function non-private or even public (though with concerns about specification difficulty) for use in
>> places like this.
>> 
>> @shipilev I'm working on a reply, but it might be long-ish.  That outpacing issue for some tests is why this
>> code wasn't switched away from jdk.internal.ref.Cleaner a long time ago.  I'm still looking at it, but I currently
>> don't think the canary provides a reliable solution to that.
>
> I would like to integrate this PR. How are you doing, @kimbarrett? Have you found any major holes in it?

@shipilev I've been having computer issues.  I'm back to looking at this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1955619941

From duke at openjdk.org  Fri Feb 14 08:31:12 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Feb 2025 08:31:12 GMT
Subject: RFR: 8349812: (fs) Files.newByteChannel with empty path name and
 CREATE_NEW throws unexpected exception [v4]
In-Reply-To: <sWpwSEm762dNGRxsjgzKJDJo-qTAQ2SuQhO2yOK1sKo=.1f24cf97-2f48-430e-ae59-6eb4a16f147c@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
 <sWpwSEm762dNGRxsjgzKJDJo-qTAQ2SuQhO2yOK1sKo=.1f24cf97-2f48-430e-ae59-6eb4a16f147c@github.com>
Message-ID: <PNmVmLaLuHhYc2DP-kHkkZCPnjh2q1C8kO4-Z1GTBmE=.e41db071-654c-4f9c-9475-4f9479ab3f4e@github.com>

On Thu, 13 Feb 2025 10:37:44 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
>> 
>> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
>> 
>> Tested by running `java/nio` tests on Linux.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the test to pass on Windows also

@mkartashev 
Your change (at version fe5c10b9b6955e722cc8851b728c880dd8f89463) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23560#issuecomment-2658584501

From mkartashev at openjdk.org  Fri Feb 14 15:32:14 2025
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 14 Feb 2025 15:32:14 GMT
Subject: Integrated: 8349812: (fs) Files.newByteChannel with empty path name
 and CREATE_NEW throws unexpected exception
In-Reply-To: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
References: <PMzCWzz3ogeN8KrJK1uLNnQHuA9lOdGpPiqagwsVavo=.f0d61b4f-3b95-4771-a6ec-f7c895901065@github.com>
Message-ID: <dubX-hrWOK8DCDDJ4prQh_EAdfpoP-3j3bmkzEaBIys=.13c42012-0fbb-478f-9bef-623c327ffd64@github.com>

On Tue, 11 Feb 2025 10:28:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> `UnixFileChannelFactory.open()` checks for the current directory by looking at the first byte of the name, which in case of an empty path is simply not there. This check throws an `ArrayIndexOutOfBoundsException` and prevents the correct exception from being thrown.
> 
> The suggested solution is to use another method that translates a path name into a byte array called `getByteArrayForSysCalls()` that is specifically designed to handle the case of empty path names.
> 
> Tested by running `java/nio` tests on Linux.

This pull request has now been integrated.

Changeset: 0414dcec
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0414dcec118fce24037ca1a6b00561c0ce4c6953
Stats:     28 lines in 2 files changed: 24 ins; 0 del; 4 mod

8349812: (fs) Files.newByteChannel with empty path name and CREATE_NEW throws unexpected exception

Reviewed-by: bpb

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

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

From duke at openjdk.org  Mon Feb 17 19:57:20 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Feb 2025 19:57:20 GMT
Subject: Withdrawn: 8310996: Add JFR event for connect operations
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <6sD5BK942SQuYweZCugrpTIeQYwDu_5TTfqxXn2iyxI=.79bae3dc-9ad0-4a1c-be03-b62d39d41043@github.com>

On Wed, 16 Oct 2024 01:19:15 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

This pull request has been closed without being integrated.

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

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

From kbarrett at openjdk.org  Tue Feb 18 11:04:24 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 18 Feb 2025 11:04:24 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
Message-ID: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>

On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert waitForReferenceProcessing removals, see JDK-8305186

There are several changes here that I think are of interest.

(1) Put the cleanables for DirectByteBuffer in a separate j.l.r.Cleaner.  I
don't think that was done in previous experiments with eliminating the use of
j.i.r.Cleaner.  That seems like a good thing to do, to avoid interleaving the
processing of these short and potentially more performance-critical cleanables
with others.

(2) Do a GC for each iteraton of the slow path (i.e. after each exponentially
increasing sleep period).  Neither the existing code (which I had a hand in)
nor its predecessor did that.  I'm currently doubtful of this being a good
idea.  The exponential backoff in the current code was just retained from the
prior code, and I think doesn't actually do much other than delay OOME to
allow other threads to happen to close any direct buffers they might be using.
In the current code (using j.i.r.Cleaner), once waitForReference returns false
all Cleaners discovered by a prior GC will have been processed.  I wonder,
with the current code, under what circumstances do we actually get into those
sleeps, but don't ultimately OOME?

To provide something similar with j.l.r.Cleaner would require an operation
on that class similar to waitForReferenceProcessing.  If there is pending
cleanup work then wait for some and then return true.  If there isn't any
pending cleanup work then return false.  I've spent some time thinking about
how this could be done, and think it's feasible (working on a prototype that
seems like it should work, but hasn't been tested at all yet), though not as
simple as one might wish.

(3) Put the slow path under a lock.  That seems clearly essential with the
change to iterate GCs.  It might be that it's a mistake in the old code to not
do something similar.  The current code allows essentially back to back to
back GCs as multiple threads hit the slow path more or less simultaneously.
You could have several threads come in and all waitForReferenceProcessing, all
finish that loop at the same time and gang-request GCs.  That doesn't seem
good.

(4) Add the canary mechanism.  I think this is a poor replacement for what
waitForReferenceProcessing does currently, since it is not even remotely
reliable.  It might make the path to OOME less likely, but bad luck could make
it do nothing useful at all.

src/java.base/share/classes/java/nio/Bits.java line 122:

> 120:         // Short on memory, with potentially many threads competing for it.
> 121:         // To alleviate progress races, acquire the lock and go slow.
> 122:         synchronized (Bits.class) {

Using a (somewhat) public object for this seems questionable.  Why not a
private lock object?

src/java.base/share/classes/java/nio/Bits.java line 156:

> 154:                 // Exponentially back off waiting for Cleaner to catch up.
> 155:                 try {
> 156:                     Thread.sleep(sleepTime);

There isn't a tryReserveMemory after the last sleep period, so that period is
just completely wasted time.  This is why the old code didn't use a for-loop
over the sleep counter, but instead checked for reaching the limit in the
middle of the loop.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2623158486
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959508352
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959509819

From shade at openjdk.org  Tue Feb 18 11:57:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 11:57:53 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v12]
In-Reply-To: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
Message-ID: <Gdz5tPwVohdf2BhnVS2juESrMlPCRXcmIxu2ydLgpHg=.b0679476-5134-4b30-bf51-db25e565a49f@github.com>

> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
> 
> We can migrate DBBs to use `java.lang.ref.Cleaner`.
> 
> There are two pecularities during this rewrite.
> 
> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
> 
> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
> 
> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

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

 - Minor post-review adjustments
 - Introduce explicit lock instead of relying on Bits.class
 - Merge branch 'master' into JDK-8344332-dbb-cleaner
 - Revert waitForReferenceProcessing removals, see JDK-8305186
 - Merge branch 'master' into JDK-8344332-dbb-cleaner
 - No instantiation for BufferCleaner, javadocs
 - Remove hasReferencePendingList
 - Revert test exclusion, moved to JDK-8348301
 - Alan's review
 - Remove vestigial reference to waitForReferenceProcessing in tests
 - ... and 8 more: https://git.openjdk.org/jdk/compare/bfcfce2e...a6ffce2e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22165/files
  - new: https://git.openjdk.org/jdk/pull/22165/files/dc3dab7f..a6ffce2e

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

  Stats: 49548 lines in 2079 files changed: 26691 ins; 11892 del; 10965 mod
  Patch: https://git.openjdk.org/jdk/pull/22165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165

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

From shade at openjdk.org  Tue Feb 18 11:57:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 11:57:54 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
Message-ID: <nTLuM2AB3FYpqO3wTBuvWBSqsAHkipQfWcTfJ6y9hwI=.7497cd81-ce48-4e55-b2cb-04f8a11f43e3@github.com>

On Tue, 18 Feb 2025 10:54:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert waitForReferenceProcessing removals, see JDK-8305186
>
> src/java.base/share/classes/java/nio/Bits.java line 122:
> 
>> 120:         // Short on memory, with potentially many threads competing for it.
>> 121:         // To alleviate progress races, acquire the lock and go slow.
>> 122:         synchronized (Bits.class) {
> 
> Using a (somewhat) public object for this seems questionable.  Why not a
> private lock object?

This class is package-private, so I judged the possibility of leaking the lock impractically low. We can do a separate lock, if that reads cleaner, sure. Done in new commit.

> src/java.base/share/classes/java/nio/Bits.java line 156:
> 
>> 154:                 // Exponentially back off waiting for Cleaner to catch up.
>> 155:                 try {
>> 156:                     Thread.sleep(sleepTime);
> 
> There isn't a tryReserveMemory after the last sleep period, so that period is
> just completely wasted time.  This is why the old code didn't use a for-loop
> over the sleep counter, but instead checked for reaching the limit in the
> middle of the loop.

Right, that's an overlook. I wanted to make the first non-sleep-ed attempt in the loop, so that it covers the semi-optimistic case where we could have reserved the memory immediately after taking the lock. But we can peel that out from the loop. Done in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959590847
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1959590929

From shade at openjdk.org  Tue Feb 18 14:33:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 14:33:16 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
Message-ID: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>

> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
> 
> We can migrate DBBs to use `java.lang.ref.Cleaner`.
> 
> There are two pecularities during this rewrite.
> 
> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
> 
> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
> 
> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  A bit more comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22165/files
  - new: https://git.openjdk.org/jdk/pull/22165/files/a6ffce2e..249ac2a7

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

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

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

From shade at openjdk.org  Tue Feb 18 14:33:17 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 18 Feb 2025 14:33:17 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v11]
In-Reply-To: <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <RQNxtymZk4gFgkve802B8cFKJEPReJwOoclLxHe43PA=.2fb4a5ed-0ef6-4914-b046-3cfab73ef8a0@github.com>
 <zm1DNJf23_u3UsjIy5JTRPH99494NdpFugBLbn7adjY=.a70bc2df-65d0-4b63-aeb1-6182eaac2dbc@github.com>
Message-ID: <D1DCQzvJNrxP6FxWXLPXnTQ6dV7hDcOvZJPSUGGap4w=.91c10819-d491-457b-987f-2bb2d251697f@github.com>

On Tue, 18 Feb 2025 11:01:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert waitForReferenceProcessing removals, see JDK-8305186
>
> There are several changes here that I think are of interest.
> 
> (1) Put the cleanables for DirectByteBuffer in a separate j.l.r.Cleaner.  I
> don't think that was done in previous experiments with eliminating the use of
> j.i.r.Cleaner.  That seems like a good thing to do, to avoid interleaving the
> processing of these short and potentially more performance-critical cleanables
> with others.
> 
> (2) Do a GC for each iteraton of the slow path (i.e. after each exponentially
> increasing sleep period).  Neither the existing code (which I had a hand in)
> nor its predecessor did that.  I'm currently doubtful of this being a good
> idea.  The exponential backoff in the current code was just retained from the
> prior code, and I think doesn't actually do much other than delay OOME to
> allow other threads to happen to close any direct buffers they might be using.
> In the current code (using j.i.r.Cleaner), once waitForReference returns false
> all Cleaners discovered by a prior GC will have been processed.  I wonder,
> with the current code, under what circumstances do we actually get into those
> sleeps, but don't ultimately OOME?
> 
> To provide something similar with j.l.r.Cleaner would require an operation
> on that class similar to waitForReferenceProcessing.  If there is pending
> cleanup work then wait for some and then return true.  If there isn't any
> pending cleanup work then return false.  I've spent some time thinking about
> how this could be done, and think it's feasible (working on a prototype that
> seems like it should work, but hasn't been tested at all yet), though not as
> simple as one might wish.
> 
> (3) Put the slow path under a lock.  That seems clearly essential with the
> change to iterate GCs.  It might be that it's a mistake in the old code to not
> do something similar.  The current code allows essentially back to back to
> back GCs as multiple threads hit the slow path more or less simultaneously.
> You could have several threads come in and all waitForReferenceProcessing, all
> finish that loop at the same time and gang-request GCs.  That doesn't seem
> good.
> 
> (4) Add the canary mechanism.  I think this is a poor replacement for what
> waitForReferenceProcessing does currently, since it is not even remotely
> reliable.  It might make the path to OOME less likely, but bad luck could make
> it do nothing useful at all.

Thanks for the comment, @kimbarrett!

I started replying, but then figured my reply on current canary mechanics would be better captured in the code comment, so I pushed it right there. Then I ran out of time. I would think about this a bit more and try to reply to the your comments sometime later this week.

So far, I still believe Cleaner canaries are the best way to balance the probability of success for the best effort attempt to allocate when short on memory and the implementation simplicity. Maybe filling the only theoretical gap I see at the moment (see code comments) would be marginally better with waiting for `Cleaner` directly, maybe not. Maybe waiting approaches strike a better balance, maybe not.

What I am sure, though, is that lots of theoretical arguments I made to myself, including re-using waiting infrastructure, failed empirical reliability/performance tests after my attempts at implementing them. Admittedly, I have not tried to go as far as coordinating _both_ reference processing and Cleaner threads, maybe, _maybe_ the answer is there. So I would reserve final judgement on whether GC+RefProc+Cleaner waiting approaches really work until I see them actually work :) In contrast, current PR both fits my theoretical understanding why it works, and passes the empirical tests. Looking forward to your attempt!

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2665881712

From kbarrett at openjdk.org  Sun Feb 23 10:23:05 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 23 Feb 2025 10:23:05 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <LcZtUjCXWicin-NhFBQKKcXSiCj5SivVMRDDf96dFO0=.5b46ddbe-959a-44a6-b689-8325770f4cad@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

I've made a prototype that adds Cleaner.waitForCleaning() and changes
Bits.reserveMemory() to use it.

https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:wait-for-cleaning?expand=1

It's based on the shipilev commits 1-19, for ease of comparison and
prototyping. There are also some shortcuts (like making some things public
that likely shouldn't be), again for ease of prototyping.

I ran the DirectBufferAllocTest test a few hundred times without any
problems.  I also ran it directly, configured with a 1/2 hour runtime, again
without problems.  I ran the two new micros against baseline, the shipilev
changes only, and the waitForCleaning changes.  Results below.

DirectByteBufferGC
baseline
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.036 ?  0.244  ms/op
DirectByteBufferGC.test    65536  avgt    9    7.117 ?  0.184  ms/op
DirectByteBufferGC.test   262144  avgt    9   18.482 ?  1.064  ms/op
DirectByteBufferGC.test  1048576  avgt    9  194.590 ? 17.639  ms/op
DirectByteBufferGC.test  4194304  avgt    9  802.354 ? 57.576  ms/op

shipilev
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.104 ?  0.045  ms/op
DirectByteBufferGC.test    65536  avgt    9    6.875 ?  0.244  ms/op
DirectByteBufferGC.test   262144  avgt    9   17.943 ?  0.446  ms/op
DirectByteBufferGC.test  1048576  avgt    9   59.002 ?  3.616  ms/op
DirectByteBufferGC.test  4194304  avgt    9  331.328 ? 36.580  ms/op

waitForCleaning
Benchmark                (count)  Mode  Cnt    Score    Error  Units
DirectByteBufferGC.test    16384  avgt    9    4.058 ?  0.167  ms/op
DirectByteBufferGC.test    65536  avgt    9    6.775 ?  0.281  ms/op
DirectByteBufferGC.test   262144  avgt    9   17.724 ?  0.602  ms/op
DirectByteBufferGC.test  1048576  avgt    9   57.284 ?  2.679  ms/op
DirectByteBufferGC.test  4194304  avgt    9  330.002 ? 44.200  ms/op

DirectByteBufferChurn
baseline
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  15.693 ? 0.991  ns/op
DirectByteBufferChurn.test          256  avgt    9  11.255 ? 0.369  ns/op
DirectByteBufferChurn.test          512  avgt    9   9.422 ? 0.382  ns/op
DirectByteBufferChurn.test         1024  avgt    9   8.529 ? 0.311  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.833 ? 0.287  ns/op

shipilev
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  12.524 ? 0.476  ns/op
DirectByteBufferChurn.test          256  avgt    9   9.248 ? 0.175  ns/op
DirectByteBufferChurn.test          512  avgt    9   8.583 ? 0.197  ns/op
DirectByteBufferChurn.test         1024  avgt    9   8.227 ? 0.274  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.526 ? 0.394  ns/op

waitForCleaning
Benchmark                   (recipFreq)  Mode  Cnt   Score   Error  Units
DirectByteBufferChurn.test          128  avgt    9  11.235 ? 1.998  ns/op
DirectByteBufferChurn.test          256  avgt    9   9.129 ? 0.324  ns/op
DirectByteBufferChurn.test          512  avgt    9   8.446 ? 0.115  ns/op
DirectByteBufferChurn.test         1024  avgt    9   7.786 ? 0.425  ns/op
DirectByteBufferChurn.test         2048  avgt    9   7.477 ? 0.150  ns/op

The baseline DirectByteBufferGC suffers significantly at higher counts,
probably because of the long doubly-linked list of registered
jdk.internal.ref.Cleaner objects.

By eye the performance of both shipilev and waitForCleaning on the DBBChurn
benchmark seem to be consistently slightly better than baseline, and within
the noise of each other for both benchmarks.

This waitForCleaning approach raises several questions.

(1) Is the improved reliability of this approach worth the additional effort?
My inclination is to say yes.  But note that it should perhaps be different
effort - see item (2).

(2) Should Cleaner be responsible for providing the additional functionality?
An alternative is to have Bits implement it's own cleaning, directly using a
private PhantomReference derivative, ReferenceQueue, and Thread.

If there were multiple (potential) clients for this sort of thing then putting
it in Cleaner may makes sense, so long as their requirements are similar.  But
we're kind of fighting with it, esp. with the canary approach, but even with
the waitForCleaning approach.  I think things could be simpler and easier to
understand with a direct implementation.  And Cleaner was not intended to be
the last word in the area of reference-based cleanup.  Rather, it's a
convenient package for addressing some common patterns (esp. with
finalization).  It provides some useful infrastructure that would need to be
replaced in a bespoke implementation, but I don't think there's anything all
that large or complicated there, and some streamlining is possible.

Note that I haven't done any work in that direction yet.

(3) Do we need the retry stuff, and how should it be done?  I did some
monitoring of the retries, and waitForCleaning DBBA does need the retries
(though rarely more than 1, and I never saw more than 2).  I kind of feel like
the retries are a kludgy workaround for what seems like an unreasonable test,
but oh well.

The point of the retries is to allow other threads to drop some DBBs that can
become reclaimable during the associated wait, giving the waiting thread an
opportunity to make use of that now available memory.

I experimented with a retry-style more similar to the current code, where each
thread on the slow path will do at most one GC and then go into a wait/sleep
loop if reservation continues to fail.  (I added some locking to avoid the
concurrent requests for GC issue with the current code.) That didn't seem to
make any difference compared to something like the proposed serialized GC and
sleep loop.  I can construct theoretical cases that seem to favor either, but
the style in the proposal seems simpler.

Of course, the question of when to do GCs and how many to do is moot if
-XX:+DisableExplicitGC is used.  (The default for that option is false.)

src/java.base/share/classes/java/nio/Bits.java line 149:

> 147:         //   1. GC needs to discover dead references and hand them over to Reference
> 148:         //      processing thread. This activity can be asynchronous and can complete after
> 149:         //      we unblock from System.gc().

Adding cleared references to the pending list is always completed before the
GC invocation completes.  Doing otherwise would break or significantly
complicate Reference.waitForReferenceProcessing(), and to no good purpose.
That function should only return false when all references cleared by a prior
GC have been enqueued in their respective queues.  There are tests that depend
on that.  (I looked, and so far as I can tell, none of the extant GCs violate
this.)

src/java.base/share/classes/java/nio/Bits.java line 166:

> 164:         // install the canary, call System.gc(), wait for canary to get processed (dead). This
> 165:         // signals that since our last call to System.gc(), steps (1) and (2) have finished, and
> 166:         // step (3) is currently in progress.

The canary having been processed doesn't tell us anything definitive about
step (2), because steps (2) and (3) occur concurrently.  The reference
processing thread transfers references to their respective queues, and the
cleaner thread processes references that have been placed in its queue, both
running at the same time.  All we know is that the canary got transferred and
cleaned.  There may or many not have been other references similarly
transferred and cleaned.  There may or may not be more references in the
pending list, in the cleaner queue, or both.  That the canary has been cleaned
doesn't give us any information about either the pending list or the cleaner
queue.

src/java.base/share/classes/java/nio/Bits.java line 172:

> 170:         // corner case would be handled with a normal retry attempt, after trying to allocate.
> 171:         // If allocation succeeds even after partial cleanup, we are done. If it does not, we get
> 172:         // to try again, this time reliably getting the results of the first cleanup run. Not

After trying again, all we know is that both the previous and the new canary
have been processed.  We don't know anything about other references, either
from the latest or preceeding GCs.  Consider this unfortunate scenario.  The
first canary ended up at the head of the pending list.  The reference
processing thread transfered it to the cleaner queue and then stalled.  The
cleaner thread processed the first canary.  The waiting thread noted that,
retried and failed the reservation, and retried the GC and wait for the
canary.  The retry canary also happened to end up at the front of the updated
pending list.  The reference processor transferred it and again stalled.  The
cleaner thread processed the retry canary.  No real cleaning has happened,
i.e. we have not reliably gotten the results of the first cleanup run.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2635485651
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720234
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720361
PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1966720509

From kbarrett at openjdk.org  Mon Feb 24 06:13:04 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Feb 2025 06:13:04 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
Message-ID: <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>

On Tue, 18 Feb 2025 14:33:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer.
>> 
>> We can migrate DBBs to use `java.lang.ref.Cleaner`.
>> 
>> There are two pecularities during this rewrite.
>> 
>> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it.
>> 
>> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us.
>> 
>> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `java/nio java/io`
>>  - [x] Linux AArch64 server fastdebug, `java/nio java/io`
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit more comments

> (2) Should Cleaner be responsible for providing the additional functionality?
> [...]
> If there were multiple (potential) clients for this sort of thing then putting
> it in Cleaner may makes sense [...]

And here is a bug and recently opened PR that would benefit from having
Cleaner.waitForCleaning.
https://bugs.openjdk.org/browse/JDK-8204868
java/util/zip/ZipFile/TestCleaner.java still fails with "cleaner failed to clean zipfile."
https://github.com/openjdk/jdk/pull/23742

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677514285

From alanb at openjdk.org  Mon Feb 24 07:28:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 24 Feb 2025 07:28:08 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
 <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
Message-ID: <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>

On Mon, 24 Feb 2025 06:10:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> And here is a bug and recently opened PR that would benefit from having Cleaner.waitForCleaning. 

If you are suggesting exposing this as a public API then I don't think we should do this, I actually think it's time to consider deprecating Cleaner but that is a bigger discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677612532

From kbarrett at openjdk.org  Mon Feb 24 09:33:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Feb 2025 09:33:06 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use
 java.lang.ref.Cleaner [v13]
In-Reply-To: <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>
References: <klctmH4lG9nPUwy8INZ3zSTWeh_Bm_eTRXNIeN2V3aA=.9c6d1ec7-1f99-4935-9919-342933451afb@github.com>
 <a-GHbyN7yRM8st2VkpokIX30TWnXQym6PmOzgvmhfFw=.1af441a3-682a-4d8c-ae8f-bad21293fdd2@github.com>
 <DRXDXe1c8hZO3rSKBDQHratQJnS4_L2eO_H_QYuIEHk=.ef10672c-f741-4987-9c59-67de4e76b7b0@github.com>
 <DpBtmZ54p8xyOHEfef89_tjdHc8amOboFsmaWXLOEzs=.a504dac1-f087-4ef2-b8e5-cf42cbba47b1@github.com>
Message-ID: <iBjBZlFeeD5TSntjrxUryLhycKbm9CldiL32kMTRiEw=.4acb6c2a-d165-4795-bd73-b07cc455b6f3@github.com>

On Mon, 24 Feb 2025 07:25:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you are suggesting exposing this as a public API then I don't think we should do this,

Not at this time, quite possibly never.  As mentioned, I made some things public for ease of prototyping.
I even commented it as such.

> I actually think it's time to consider deprecating Cleaner but that is a bigger discussion.

Which "Cleaner" are you referring to?  If jdk.internal.ref.Cleaner, this PR proposes to remove it.
If java.lang.ref.Cleaner, then why?

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

PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2677851956

From duke at openjdk.org  Wed Feb 26 01:36:58 2025
From: duke at openjdk.org (Dustin4444)
Date: Wed, 26 Feb 2025 01:36:58 GMT
Subject: RFR: 8349689: Several virtual thread tests missing /native keyword
 [v5]
In-Reply-To: <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
References: <c54r827muR8LjT3MkeZ5gpBnS_TKXeXayXZeSrRvmBk=.5b14b913-d6c2-452e-861b-78b8b37e1377@github.com>
 <NNlLiauSRzBlQNJVBRGYUQx4pn6I-Qen6jU73yDjhr4=.35d15ad1-0bfe-4dd4-85aa-87b7e4034f48@github.com>
Message-ID: <vZw_vPmBI2DH_U4CkbHYnqqu2wCqCXBU7AtAYQAO6Do=.9e493748-bb46-4f69-81a7-0fb9de340d7c@github.com>

On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan <syan at openjdk.org> wrote:

>> H all,
>> 
>> This PR add `/native` keyword in the test header for virtual thread tests. The `/native` keyword will make run the related tests by jtreg standalone more friendly.
>> 
>> I runed all the tests without -nativepath argument and find the fail tests. This will find all the virtual thread tests which missing '/native' flag.
>> 
>> 1. java/lang/management/ThreadMXBean/VirtualThreads.java#default
>> 
>> VirtualThreads.java:223 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> java/lang/management/ThreadMXBean/VirtualThreads.java#no-vmcontinuations run this test with VM option "-XX:-VMContinuations" and `assumeTrue(VThreadScheduler.supportsCustomScheduler(), "No support for custom schedulers");` will make junit skip the 'testGetThreadInfoCarrierThread' unit test, so 'VirtualThreads.java#no-vmcontinuations' do not need '/native' keywork.
>> 
>> 2. java/lang/Thread/virtual/stress/PinALot.java
>> 
>> PinALot.java:58 call "invoker()" in test/lib/jdk/test/lib/thread/VThreadPinner.java file, which will call the native function "call".
>> 
>> 3. java/lang/Thread/virtual/SynchronizedNative.java
>> 
>> Call System.loadLibrary("SynchronizedNative") at line 85.
>> 
>> 4. Tests java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java, java/lang/Thread/virtual/ThreadAPI.java, java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java, java/lang/Thread/virtual/MonitorWaitNotify.java, java/lang/Thread/virtual/MonitorPinnedEvents.java, java/lang/Thread/virtual/MonitorEnterExit.java and other tests are similar to java/lang/Thread/virtual/stress/PinALot.java
>> 
>> 
>> - Why we need the '/native' keywork?
>> 
>> I usually run the tests through jtreg directively, rather than run the tests through make test. If I run the test which load the native shared library files and the test missing '/native' keyword but I forgot to pass the '-nativepath' argument to jtreg, or pass the incorrect '-nativepath' argument to jtreg, sometimes it will report timeouted after a long time, such as java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native' keywork, jtreg will report 'Error. Use -nativepath to specify the location of native code' right away. So add the missing '/native' keyword will make run the tests more friendly.
>> 
>> Change has been verified locally, test-fix, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the additional check for virtual thread of test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Marked as reviewed by Dustin4444 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/23550#pullrequestreview-2642819217

From bpb at openjdk.org  Wed Feb 26 18:46:36 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Feb 2025 18:46:36 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
Message-ID: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>

Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

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

Commit messages:
 - 8350654: (fs) Files.createTempDirectory should say something about the default file permissions when no file attributes specified

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

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

From bpb at openjdk.org  Wed Feb 26 18:51:02 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 26 Feb 2025 18:51:02 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
In-Reply-To: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
Message-ID: <tD6inazBwXng5LWSgqlKcOG_BVt0vik6nMe_hz-kqnk=.44469200-942a-4e36-b78f-235429888269@github.com>

On Wed, 26 Feb 2025 18:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

For example, on macOS, without attributes supplied, `Files.createTempDirectory` creates a directory with mode `drwx------`  and `Files.createDirectory` one with mode `drwxr-xr-x`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23808#issuecomment-2685909386

From alanb at openjdk.org  Wed Feb 26 19:57:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Feb 2025 19:57:02 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
In-Reply-To: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
Message-ID: <NDXPmLoeuihefkxs0MzwNMVL5eBQmy2nbcaxbpMXDhA=.f1c2207d-bb46-4638-9e06-1a4dfec7208e@github.com>

On Wed, 26 Feb 2025 18:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

Same wording as createTempFile so I think this is okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23808#pullrequestreview-2645731536

From alanb at openjdk.org  Thu Feb 27 06:44:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 06:44:57 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
In-Reply-To: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
Message-ID: <cdJvVL4_ryUw4sEqMG-rfgOxhwkI149bq_BXuX0XRv8=.10e423c7-1201-4cf3-be8b-a1f738c84348@github.com>

On Wed, 26 Feb 2025 18:40:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

src/java.base/share/classes/java/nio/file/Files.java line 865:

> 863:      * the last occurrence is ignored. When no file attributes are specified,
> 864:      * then the resulting directory may have more restrictive access
> 865:      * permissions to (non-temporary) directories created by the

I re-read the text again and I think it would be better to drop "non-temporary" from this sentence. It would read better without it, and avoids introducing a new term.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23808#discussion_r1972967198

From bpb at openjdk.org  Thu Feb 27 16:45:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Feb 2025 16:45:03 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
In-Reply-To: <cdJvVL4_ryUw4sEqMG-rfgOxhwkI149bq_BXuX0XRv8=.10e423c7-1201-4cf3-be8b-a1f738c84348@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
 <cdJvVL4_ryUw4sEqMG-rfgOxhwkI149bq_BXuX0XRv8=.10e423c7-1201-4cf3-be8b-a1f738c84348@github.com>
Message-ID: <2zsv4RkQYA6Vll-5zZdxwimXQLXTQ_3hqUfKOFjGT2o=.29ceba89-9068-484d-8a8d-e607c24c9317@github.com>

On Thu, 27 Feb 2025 06:41:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.
>
> src/java.base/share/classes/java/nio/file/Files.java line 865:
> 
>> 863:      * the last occurrence is ignored. When no file attributes are specified,
>> 864:      * then the resulting directory may have more restrictive access
>> 865:      * permissions to (non-temporary) directories created by the
> 
> I re-read the text again and I think it would be better to drop "non-temporary" from this sentence. It would read better without it, and avoids introducing a new term.

I was actually unsure of that also; will change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23808#discussion_r1973966725

From bpb at openjdk.org  Thu Feb 27 17:16:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Feb 2025 17:16:35 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
 [v2]
In-Reply-To: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
Message-ID: <PKXHpchERRNwgSCB8d3QTW8-Kup8lgpq8xr1FOfppkw=.9ca5f3b7-9c79-4563-9079-dc1bb3f1ddf4@github.com>

> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.

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

  8350654: Remove "(non-temporary)"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23808/files
  - new: https://git.openjdk.org/jdk/pull/23808/files/406ecbf7..b99cf8fe

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

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

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

From bpb at openjdk.org  Thu Feb 27 17:16:35 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 27 Feb 2025 17:16:35 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
 [v2]
In-Reply-To: <2zsv4RkQYA6Vll-5zZdxwimXQLXTQ_3hqUfKOFjGT2o=.29ceba89-9068-484d-8a8d-e607c24c9317@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
 <cdJvVL4_ryUw4sEqMG-rfgOxhwkI149bq_BXuX0XRv8=.10e423c7-1201-4cf3-be8b-a1f738c84348@github.com>
 <2zsv4RkQYA6Vll-5zZdxwimXQLXTQ_3hqUfKOFjGT2o=.29ceba89-9068-484d-8a8d-e607c24c9317@github.com>
Message-ID: <spbCid3DM017GhS2HtuDra1gBGMpZWP6obiGTd4g81s=.500dee62-ae78-4987-8a8f-0c69c2c8e914@github.com>

On Thu, 27 Feb 2025 16:42:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Files.java line 865:
>> 
>>> 863:      * the last occurrence is ignored. When no file attributes are specified,
>>> 864:      * then the resulting directory may have more restrictive access
>>> 865:      * permissions to (non-temporary) directories created by the
>> 
>> I re-read the text again and I think it would be better to drop "non-temporary" from this sentence. It would read better without it, and avoids introducing a new term.
>
> I was actually unsure of that also; will change.

> it would be better to drop "non-temporary"

So changed in b99cf8f and CSR updated to match.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23808#discussion_r1974016700

From alanb at openjdk.org  Thu Feb 27 17:45:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Feb 2025 17:45:00 GMT
Subject: RFR: 8350654: (fs) Files.createTempDirectory should say something
 about the default file permissions when no file attributes specified
 [v2]
In-Reply-To: <PKXHpchERRNwgSCB8d3QTW8-Kup8lgpq8xr1FOfppkw=.9ca5f3b7-9c79-4563-9079-dc1bb3f1ddf4@github.com>
References: <oiMoeht9DhZM156-0PXTv3Oxud54L1ubUPFOXN-qfyY=.4ab76939-694a-4296-b8ac-104a151f9ab3@github.com>
 <PKXHpchERRNwgSCB8d3QTW8-Kup8lgpq8xr1FOfppkw=.9ca5f3b7-9c79-4563-9079-dc1bb3f1ddf4@github.com>
Message-ID: <rT2ztNQcPBqrRKxUcY4ZsR8lD7yLcyLImJYw5nmhplM=.ea5ba9c9-8e96-45a0-bdc1-e4d73dc563b4@github.com>

On Thu, 27 Feb 2025 17:16:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a sentence clarifying the behavior of `Files.createTempDirectory(Path,String,FileAttribute<?>...)` when no attributes are specified.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8350654: Remove "(non-temporary)"

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23808#pullrequestreview-2648591003