From smarks at openjdk.org  Tue Oct  1 03:41:40 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 03:41:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

test/jdk/java/lang/StringBuffer/HugeCapacity.java line 51:

> 49:             // Maximum array length supported by the JVM implementation
> 50:             int maxArrayLength = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;
> 51:             String str = "Z".repeat(maxArrayLength);

Same comment as in the corresponding code in the StringBuilder test.

test/jdk/java/lang/StringBuilder/HugeCapacity.java line 83:

> 81:             // Maximum array length supported by the JVM implementation
> 82:             int maxArrayLength = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;
> 83:             String str = "Z".repeat(maxArrayLength);

The comment is a bit misleading. I'm not sure any comment is warranted, as you had observed, there's a big description next to SOFT_MAX_ARRAY_LENGTH. I'm also not sure a new local variable maxArrayLength adds anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782068899
PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782068601

From smarks at openjdk.org  Tue Oct  1 04:03:34 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 04:03:34 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.

I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The *real* fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.

As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2384736938

From eirbjo at openjdk.org  Tue Oct  1 05:39:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:39:09 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove comment and variable from HugeCapacity tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21268/files
  - new: https://git.openjdk.org/jdk/pull/21268/files/eb1c6551..67ed8e47

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

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

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

From eirbjo at openjdk.org  Tue Oct  1 05:39:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:39:09 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>
Message-ID: <YSUHxKQYrKRQQGNXkh-Yslp0kM15Yz_di6HB54JQiG0=.1873ba60-2654-4f54-a90d-f7e2e9b60ae1@github.com>

On Tue, 1 Oct 2024 03:38:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> The comment is a bit misleading. I'm not sure any comment is warranted, as you had observed, there's a big description next to SOFT_MAX_ARRAY_LENGTH. I'm also not sure a new local variable maxArrayLength adds anything.

Thanks, I have removed the comment and variable for these two tests.

I guess I felt SOFT_MAX_ARRAY_LENGTH looked a bit lonely here, given that it was just used as an argument and had no constant or comment like in most other instances. But I agree that the comment and the variable does not add much value here, the name of the test makes it clear that this is about capacity and the documentation on SOFT_MAX_ARRAY_LENGTH is just a click away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782140912

From eirbjo at openjdk.org  Tue Oct  1 05:54:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:54:35 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
Message-ID: <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>

On Tue, 1 Oct 2024 04:01:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.

I was pondering a bit whether to include tests. The use of the constant perhaps aids understanding even more here, because the value might seem "more magic" , being  further removed from where actual allocation takes place. Tests are a useful tool for understanding APIs and their implementation, so less magic feels like an improvement. Also, we want to update tests as well if the implementation limit is lifted, this makes that update easier.  

> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The _real_ fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.

Good, I initially included code outside `java.base`, but that quicly got messy.

> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.

Thanks for the JLS pointer, good that this is not just a javac implementation detail.
 
Confirmed this using:

% javap -c -p -constants java.io.InputStream | grep MAX_BUFFER_SIZE`
private static final int MAX_BUFFER_SIZE = 2147483639;
% javap -c -p -constants java.io.InputStream  | grep ArraySupport

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2384860067

From alanb at openjdk.org  Tue Oct  1 08:50:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Oct 2024 08:50:42 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <UgHXq4ewqpXU9U_Q_VcFKTDnDQgyI300ktVu7km3ZNs=.1feda93a-1d4e-42ab-99b0-db12c445d179@github.com>

On Mon, 30 Sep 2024 22:57:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 167:

> 165:     @Override
> 166:     public FileTime creationTime() {
> 167:         if (UnixNativeDispatcher.birthtimeSupported() && !birthtime_invalid) {

If you invert and rename this from "invalid" to "valid" then it would improve the readability.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 630:

> 628:                          (jlong)buf->stx_btime.tv_sec);
> 629:     (*env)->SetLongField(env, attrs, attrs_st_birthtime_nsec,
> 630:                          (jlong)buf->stx_btime.tv_nsec);

If you allow the lines to be just a bit long then it would avoid the line splits in this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782373291
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782372966

From jpai at openjdk.org  Tue Oct  1 08:52:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Oct 2024 08:52:39 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <eRCLAhbToWcqRDN6OVHm3R4jaJlNvLFsEVfbuV68cTQ=.6d1fecc4-69a0-42d0-8543-6208cb2dc5f4@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Hello Eirik, these changes look OK to me. Referring to this constant instead of the `Integer.MAX_VALUE - 8` is useful for the context of that value, especially in some places like the usage in `Pattern` class.
As for the test changes, I think it's OK to refer this there too, given that several of these tests are actually wanting to use a value which implies the maximum limit on the array length.
>From what I remember, adding a `@modules` in test definition makes the test run as "othervm" (even if othervm isn't explicitly specified). But I think that shouldn't matter much, at least not in this PR, because all the test definitions that are changed in this PR are already othervm (explicitly).

I am going to run tier tests against this PR in our CI. Please wait for that run to complete, before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21268#pullrequestreview-2339549362

From sgehwolf at openjdk.org  Tue Oct  1 09:06:37 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 09:06:37 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <YPrPEBy6lms9pLiNqUlujxC00KHhweQAwTJMRmKu11A=.663c655a-579c-4269-9b4a-c3a13b20e6ba@github.com>

On Mon, 30 Sep 2024 22:57:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

As for the test, we should also consider getting https://github.com/openjdk/jdk/pull/20687 in since it currently doesn't handle all cases which this patch again touches. Specifically some systems with the correct kernel/glibc combination but on a filesystem without support the test is broken as-is.

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 61:

> 59:     private long    st_birthtime_sec;
> 60:     private long    st_birthtime_nsec;
> 61:     private boolean birthtime_invalid;

Suggestion:

    private boolean birthtime_filled_in;


Perhaps we should add a comment that this is Linux-only and will only be true for Linux filesystems that support birth time.

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 167:

> 165:     @Override
> 166:     public FileTime creationTime() {
> 167:         if (UnixNativeDispatcher.birthtimeSupported() && !birthtime_invalid) {

Suggestion:

        if (UnixNativeDispatcher.birthtimeSupported() && birthtime_filled_in) {

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 186:

> 184: #if defined(__linux__) // Linux has nsec granularity if supported
> 185: static jfieldID attrs_st_birthtime_nsec;
> 186: static jfieldID attrs_birthtime_invalid;

Suggestion:

static jfieldID attrs_birthtime_filled_in;

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 336:

> 334:     CHECK_NULL_RETURN(attrs_st_birthtime_nsec, 0);
> 335: 
> 336:     attrs_birthtime_invalid = (*env)->GetFieldID(env, clazz, "birthtime_invalid", "Z");

Suggestion:

    attrs_birthtime_filled_in = (*env)->GetFieldID(env, clazz, "birthtime_filled_in", "Z");

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 337:

> 335: 
> 336:     attrs_birthtime_invalid = (*env)->GetFieldID(env, clazz, "birthtime_invalid", "Z");
> 337:     CHECK_NULL_RETURN(attrs_birthtime_invalid, 0);

Suggestion:

    CHECK_NULL_RETURN(attrs_birthtime_filled_in, 0);

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 636:

> 634:         JNI_FALSE : JNI_TRUE;
> 635:     (*env)->SetBooleanField(env, attrs, attrs_birthtime_invalid,
> 636:                             birthtime_invalid);

Suggestion:

    // Only set birthtime_filled_in to true when the returned mask indicates so.
    // Note that on some (Linux) filesystems birth time is not supported while it is supported for others.
    jboolean birthtime_filled_in = (buf->stx_mask & STATX_BTIME) != 0 ?
        JNI_TRUE : JNI_FALSE;
    (*env)->SetBooleanField(env, attrs, attrs_birthtime_filled_in,
                            birthtime_filled_in);

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

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2339565204
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782391038
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782395796
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782397239
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782397711
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782398381
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1782402791

From smarks at openjdk.org  Tue Oct  1 15:45:39 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 15:45:39 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <SxL_WkU_G5sjVYLrZwhKyDBm_B5I1ryrQYp8wzV1Xek=.880c20d0-5245-47e5-8186-c37f5cc688f2@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21268#pullrequestreview-2340765971

From smarks at openjdk.org  Tue Oct  1 15:45:40 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 15:45:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
 <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>
Message-ID: <kuxkbvZxpTC3Ealo9oEte922TsySKqIa8kotJeiXs_I=.aab96cbc-5041-4724-bde1-1b5b79e4e2f6@github.com>

On Tue, 1 Oct 2024 05:52:23 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.
>> 
>> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The *real* fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.
>> 
>> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.
>
>> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.
> 
> I was pondering a bit whether to include tests. The use of the constant perhaps aids understanding even more here, because the value might seem "more magic" , being  further removed from where actual allocation takes place. Tests are a useful tool for understanding APIs and their implementation, so less magic feels like an improvement. Also, we want to update tests as well if the implementation limit is lifted, this makes that update easier.  
> 
>> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The _real_ fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.
> 
> Good, I initially included code outside `java.base`, but that quicly got messy.
> 
>> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.
> 
> Thanks for the JLS pointer, good that this is not just a javac implementation detail.
>  
> Confirmed this using:
> 
> % javap -c -p -constants java.io.InputStream | grep MAX_BUFFER_SIZE`
> private static final int MAX_BUFFER_SIZE = 2147483639;
> % javap -c -p -constants java.io.InputStream  | grep ArraySupport

@eirbjo Thanks for your thoughts on using the constant in the tests. It all makes good sense.

@jaikiran Thanks for handling testing for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2386362465

From bpb at openjdk.org  Tue Oct  1 16:10:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 16:10:36 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
In-Reply-To: <UgHXq4ewqpXU9U_Q_VcFKTDnDQgyI300ktVu7km3ZNs=.1feda93a-1d4e-42ab-99b0-db12c445d179@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <UgHXq4ewqpXU9U_Q_VcFKTDnDQgyI300ktVu7km3ZNs=.1feda93a-1d4e-42ab-99b0-db12c445d179@github.com>
Message-ID: <uYYEviQWfAC9D_GszVX8KzE7dbRDOkv-yu1dnHpJrc0=.cf40ba70-710f-4b25-bfc6-e4f1316aa994@github.com>

On Tue, 1 Oct 2024 08:48:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 167:
> 
>> 165:     @Override
>> 166:     public FileTime creationTime() {
>> 167:         if (UnixNativeDispatcher.birthtimeSupported() && !birthtime_invalid) {
> 
> If you invert and rename this from "invalid" to "valid" then it would improve the readability.

I agree as long as it initialized to `true`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1783141822

From bpb at openjdk.org  Tue Oct  1 16:13:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 16:13:39 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
In-Reply-To: <YPrPEBy6lms9pLiNqUlujxC00KHhweQAwTJMRmKu11A=.663c655a-579c-4269-9b4a-c3a13b20e6ba@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <YPrPEBy6lms9pLiNqUlujxC00KHhweQAwTJMRmKu11A=.663c655a-579c-4269-9b4a-c3a13b20e6ba@github.com>
Message-ID: <eXfEJ8DclhlRmN2vz6IZhYa4waLsiKGO4xT71GljB-8=.d494674b-8c1d-4658-bb7b-42c6d2ab5a6e@github.com>

On Tue, 1 Oct 2024 08:52:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 61:
> 
>> 59:     private long    st_birthtime_sec;
>> 60:     private long    st_birthtime_nsec;
>> 61:     private boolean birthtime_invalid;
> 
> Suggestion:
> 
>     private boolean birthtime_filled_in;
> 
> 
> Perhaps we should add a comment that this is Linux-only and will only be true for Linux filesystems that support birth time.

Maybe `birthtime_valid` or `birthtime_available`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1783146283

From eirbjo at openjdk.org  Tue Oct  1 16:17:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 16:17:35 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <v_UyMOjDYMVKU2v7tqxOJfOeoHX0e3JdHaEkPi-tPo4=.2390255b-1ddb-42f9-b81a-017490936d30@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Thanks for taking time to review this Stuart. 

I'm delegating the integration of this PR such that @jaikiran can take care of that once his test run is complete.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2386435858

From sgehwolf at openjdk.org  Tue Oct  1 16:23:39 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 16:23:39 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
In-Reply-To: <eXfEJ8DclhlRmN2vz6IZhYa4waLsiKGO4xT71GljB-8=.d494674b-8c1d-4658-bb7b-42c6d2ab5a6e@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <YPrPEBy6lms9pLiNqUlujxC00KHhweQAwTJMRmKu11A=.663c655a-579c-4269-9b4a-c3a13b20e6ba@github.com>
 <eXfEJ8DclhlRmN2vz6IZhYa4waLsiKGO4xT71GljB-8=.d494674b-8c1d-4658-bb7b-42c6d2ab5a6e@github.com>
Message-ID: <HYZSC_S6i-NYJ5AAybW9tM-_5TktzNTuoPs9LHbc0kw=.de95df9f-908e-404e-8120-4d27ab527d5d@github.com>

On Tue, 1 Oct 2024 16:11:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 61:
>> 
>>> 59:     private long    st_birthtime_sec;
>>> 60:     private long    st_birthtime_nsec;
>>> 61:     private boolean birthtime_invalid;
>> 
>> Suggestion:
>> 
>>     private boolean birthtime_filled_in;
>> 
>> 
>> Perhaps we should add a comment that this is Linux-only and will only be true for Linux filesystems that support birth time.
>
> Maybe `birthtime_valid` or `birthtime_available`?

`birthtime_available` seems to more clearly indicate what's happening. Technically a zero is also valid :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1783158313

From bpb at openjdk.org  Tue Oct  1 17:37:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 17:37:49 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v2]
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

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

  8341282: birthtime_invalid -> birthtime_available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21274/files
  - new: https://git.openjdk.org/jdk/pull/21274/files/c36d867a..e0bd5b07

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

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

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

From bpb at openjdk.org  Tue Oct  1 17:42:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 17:42:34 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v2]
In-Reply-To: <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
Message-ID: <gc3VYLqODGPDTD6goII_J0sluvPZ8bfhd239e9SobRY=.f03a029b-67b4-4cbc-9486-4aec1fe5215e@github.com>

On Tue, 1 Oct 2024 17:37:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: birthtime_invalid -> birthtime_available

Please ignore commit e0bd5b0, at least for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21274#issuecomment-2386591565

From sgehwolf at openjdk.org  Tue Oct  1 18:21:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 18:21:36 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v2]
In-Reply-To: <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
Message-ID: <f90uNtaz8ls_vwEzs74tTrCkZNvyA6-S5oCB1VlQu0g=.e50a6cc7-abe5-447e-ad38-2d916993f1c3@github.com>

On Tue, 1 Oct 2024 17:37:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: birthtime_invalid -> birthtime_available

LGTM

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 633:

> 631:     // filled in if and only if the STATX_BTIME bit is set in the mask.
> 632:     // Although the statx system call might be supported by the operating
> 633:     // system, the birth time is not necessarily supported by the file system.

Nice comment!

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2341091855
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1783306033

From sgehwolf at openjdk.org  Tue Oct  1 18:24:37 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 18:24:37 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v2]
In-Reply-To: <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
Message-ID: <_i0Gpx_DyXa_rr3mZyQ_CsMZCuMVd4vxzIFjizoFUzA=.ecf81cd5-7913-4f8d-88a2-7bf159f10c00@github.com>

On Tue, 1 Oct 2024 17:37:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: birthtime_invalid -> birthtime_available

> Please ignore commit [e0bd5b0](https://github.com/openjdk/jdk/commit/e0bd5b07983c98c3fa2cd1dcba87cfec469ea3ac), at least for now.

Saw this too late...

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

PR Comment: https://git.openjdk.org/jdk/pull/21274#issuecomment-2386676650

From bpb at openjdk.org  Tue Oct  1 19:57:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 19:57:52 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v3]
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

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

  8341282: Unset birthtime_available when using stat(2) on Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21274/files
  - new: https://git.openjdk.org/jdk/pull/21274/files/e0bd5b07..22ac46ea

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

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

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

From bpb at openjdk.org  Tue Oct  1 19:57:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 19:57:53 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v2]
In-Reply-To: <_i0Gpx_DyXa_rr3mZyQ_CsMZCuMVd4vxzIFjizoFUzA=.ecf81cd5-7913-4f8d-88a2-7bf159f10c00@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <yRRiiqgeS-EYLtJG4DYMiLxSC_m7cIIVz-3LJqN9lWQ=.16540738-9540-4386-9e68-80973d70954f@github.com>
 <_i0Gpx_DyXa_rr3mZyQ_CsMZCuMVd4vxzIFjizoFUzA=.ecf81cd5-7913-4f8d-88a2-7bf159f10c00@github.com>
Message-ID: <hKlfmu8HI14ZZwbUGzFGVnTXbcINUf5l-YGzuBrRHdc=.b286df8a-4942-4bec-9049-c58f4a3238e8@github.com>

On Tue, 1 Oct 2024 18:21:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Saw this too late...

No worries. The only thing different in 22ac46e is setting `birthtime_available = false` when `stat(2)` is used on Linux.

> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 633:
> 
>> 631:     // filled in if and only if the STATX_BTIME bit is set in the mask.
>> 632:     // Although the statx system call might be supported by the operating
>> 633:     // system, the birth time is not necessarily supported by the file system.
> 
> Nice comment!

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21274#issuecomment-2386939481
PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1783442355

From jpai at openjdk.org  Wed Oct  2 01:29:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Oct 2024 01:29:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <un4GBh68csaCCY2QIHBD5R8jkMOhLDEpiZyBCdvNy5A=.bd295084-a190-4c14-b7e9-7d63d1e021e1@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

tier1, tier2 and tier3 testing in our CI completed without any issues. I'll now go ahead with integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2387457683

From eirbjo at openjdk.org  Wed Oct  2 01:29:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 2 Oct 2024 01:29:41 GMT
Subject: Integrated: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max
 array size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <Yv0AQvnND_IRghP2dgMt-7H_U5nLeWq23KNh5y40U4s=.20f3be08-1637-460c-a883-f91c4cc2651d@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

This pull request has now been integrated.

Changeset: 0f381137
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f381137cb9338453a7d77a7ebdfaa9b34b5028b
Stats:     60 lines in 15 files changed: 19 ins; 9 del; 32 mod

8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array size in java.base

Reviewed-by: jpai, smarks

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

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

From sgehwolf at openjdk.org  Wed Oct  2 09:12:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 09:12:35 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v3]
In-Reply-To: <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
Message-ID: <S9NDykxWPLlm5hj3eRVXs4XRyqGTypANYrIPpWACCeM=.c8524c17-b240-4518-9da2-0275e375c993@github.com>

On Tue, 1 Oct 2024 19:57:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: Unset birthtime_available when using stat(2) on Linux

If I'm understanding this correctly the default value of `birthtime_available = true` is to account for the fact that on MacOSX birth time support is not conditional on the filesystem. It's assumed to always be supported. On Linux, on the other hand, it's filesystem dependent.

What's strange is that in https://github.com/openjdk/jdk/pull/21274/commits/22ac46eab211ca32ab046283c6a7efcf215425a8 we set birth time support to false, but we should never enter this code `copy_stat_attributes()` on Linux since we set the capability i.e. `UnixNativeDispatcher.birthtimeSupported()` to true iff `statx` is available and then we'd use `copy_statx_attributes()` instead. So it makes little sense to set both on Linux: capabilities and `birthtime_available` in `copy_stat_attributes()` since it should never end up there for the birth time supported case.

How about keeping `birthtime_available` default `false` (no explicit initialization) and do this in `copy_stat_attributes()`:


static void copy_stat_attributes(JNIEnv* env, struct stat* buf, jobject attrs) {
    (*env)->SetIntField(env, attrs, attrs_st_mode, (jint)buf->st_mode);
    (*env)->SetLongField(env, attrs, attrs_st_ino, (jlong)buf->st_ino);
    (*env)->SetLongField(env, attrs, attrs_st_dev, (jlong)buf->st_dev);
    (*env)->SetLongField(env, attrs, attrs_st_rdev, (jlong)buf->st_rdev);
    (*env)->SetIntField(env, attrs, attrs_st_nlink, (jint)buf->st_nlink);
    (*env)->SetIntField(env, attrs, attrs_st_uid, (jint)buf->st_uid);
    (*env)->SetIntField(env, attrs, attrs_st_gid, (jint)buf->st_gid);
    (*env)->SetLongField(env, attrs, attrs_st_size, (jlong)buf->st_size);
    (*env)->SetLongField(env, attrs, attrs_st_atime_sec, (jlong)buf->st_atime);
    (*env)->SetLongField(env, attrs, attrs_st_mtime_sec, (jlong)buf->st_mtime);
    (*env)->SetLongField(env, attrs, attrs_st_ctime_sec, (jlong)buf->st_ctime);
#ifdef _DARWIN_FEATURE_64_BIT_INODE
   // birthtime_available defaults to 'false'. On Darwin, it's unconditionally true
   (*env)->SetBooleanField(env, attrs, attrs_birthtime_available,
                            (jboolean)JNI_TRUE);
    (*env)->SetLongField(env, attrs, attrs_st_birthtime_sec, (jlong)buf->st_birthtime);
    // rely on default value of 0 for st_birthtime_nsec field on Darwin
#endif


This would avoid the confusing part of having to think about why the Linux code ends up dealing with birth time support in `copy_stat_attributes()` to begin with.

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

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2342274026

From alanb at openjdk.org  Wed Oct  2 13:51:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 13:51:39 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v3]
In-Reply-To: <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
Message-ID: <87dTdUD34fO_WTFggloE4ORpVV4NlGapSeVMUQk1XBs=.1975b4a6-fcfe-4d69-958d-52bfaabd666f@github.com>

On Tue, 1 Oct 2024 19:57:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: Unset birthtime_available when using stat(2) on Linux

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 61:

> 59:     private long    st_birthtime_sec;
> 60:     private long    st_birthtime_nsec;
> 61:     private boolean birthtime_available = true;

I have a mild preference to leave the default be false, then set it to true in the native code when setting the birth time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1784565290

From bpb at openjdk.org  Wed Oct  2 15:28:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 15:28:37 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v3]
In-Reply-To: <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <n4gSSZQ8R0CDzdIxipf7opZIfnMRF2YGA5YO-PPbXfU=.4d7edb7e-4ba1-43d7-acc0-577b7f38dc78@github.com>
Message-ID: <hscFpcFqFzO1RWxgTxgZM2-VY3WNn5Zo6K4Ja-jDsXM=.fecb6a08-5258-4ad2-ac8e-3df10c467de5@github.com>

On Tue, 1 Oct 2024 19:57:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: Unset birthtime_available when using stat(2) on Linux

> What's strange is that in [22ac46e](https://github.com/openjdk/jdk/commit/22ac46eab211ca32ab046283c6a7efcf215425a8) we set birth time support to false, but we should never enter this code `copy_stat_attributes()` on Linux since we set the capability i.e. `UnixNativeDispatcher.birthtimeSupported()` to true iff `statx` is available and then we'd use `copy_statx_attributes()` instead.

Yes, I was aware of that. The change was a sort of attempt at completeness, but I think too confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21274#issuecomment-2388969246

From bpb at openjdk.org  Wed Oct  2 16:54:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 16:54:24 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

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

  8341282: Make birthtime_available default false and set to true where needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21274/files
  - new: https://git.openjdk.org/jdk/pull/21274/files/22ac46ea..4a4cde9b

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

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

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

From sgehwolf at openjdk.org  Wed Oct  2 16:56:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 16:56:44 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
Message-ID: <MnJRwtsC_ZAr8iOhPsWEVvmxaBR62RFRZ6Lbfso4aa8=.e7c0b7c9-78fa-4af5-a42b-3bea611be4d3@github.com>

On Wed, 2 Oct 2024 16:54:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: Make birthtime_available default false and set to true where needed

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2343535168

From alanb at openjdk.org  Wed Oct  2 17:17:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 17:17:40 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
Message-ID: <5KsawcB84bN5n-lTa6LQxDUPvJwPLAHmwHYOkAmoBVM=.8133d3cb-1c40-42b1-8f3f-17a3ecca7703@github.com>

On Wed, 2 Oct 2024 16:54:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: Make birthtime_available default false and set to true where needed

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 629:

> 627:     (*env)->SetLongField(env, attrs, attrs_st_birthtime_sec, (jlong)buf->stx_btime.tv_sec);
> 628:     (*env)->SetLongField(env, attrs, attrs_st_birthtime_nsec, (jlong)buf->stx_btime.tv_nsec);
> 629: 

I think I need a reminder as to why we put values into these two fields when not available.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1784926276

From bpb at openjdk.org  Wed Oct  2 17:20:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 17:20:41 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <5KsawcB84bN5n-lTa6LQxDUPvJwPLAHmwHYOkAmoBVM=.8133d3cb-1c40-42b1-8f3f-17a3ecca7703@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
 <5KsawcB84bN5n-lTa6LQxDUPvJwPLAHmwHYOkAmoBVM=.8133d3cb-1c40-42b1-8f3f-17a3ecca7703@github.com>
Message-ID: <XcRb4aJ2E-MZ6bZsddln48ia1VuVMdBeeobeWWo7hWg=.564d94e2-a139-4aa9-976b-dc709aaa6b60@github.com>

On Wed, 2 Oct 2024 17:14:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think I need a reminder as to why we put values into these two fields when not available.

There's no reason to do so except to avoid testing availability.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1784930213

From alanb at openjdk.org  Wed Oct  2 17:27:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 17:27:42 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <XcRb4aJ2E-MZ6bZsddln48ia1VuVMdBeeobeWWo7hWg=.564d94e2-a139-4aa9-976b-dc709aaa6b60@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
 <5KsawcB84bN5n-lTa6LQxDUPvJwPLAHmwHYOkAmoBVM=.8133d3cb-1c40-42b1-8f3f-17a3ecca7703@github.com>
 <XcRb4aJ2E-MZ6bZsddln48ia1VuVMdBeeobeWWo7hWg=.564d94e2-a139-4aa9-976b-dc709aaa6b60@github.com>
Message-ID: <TLmxPztIA9GDXOK1UqlUFRvZzCLvf-6gWey7lHBZnsg=.f96033ff-bbd5-4a7b-b620-c748db76a012@github.com>

On Wed, 2 Oct 2024 17:18:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 629:
>> 
>>> 627:     (*env)->SetLongField(env, attrs, attrs_st_birthtime_sec, (jlong)buf->stx_btime.tv_sec);
>>> 628:     (*env)->SetLongField(env, attrs, attrs_st_birthtime_nsec, (jlong)buf->stx_btime.tv_nsec);
>>> 629: 
>> 
>> I think I need a reminder as to why we put values into these two fields when not available.
>
>> I think I need a reminder as to why we put values into these two fields when not available.
> 
> There's no reason to do so except to avoid testing availability.

It still must test, in order to set the right value for the new available field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1784937246

From bpb at openjdk.org  Wed Oct  2 17:27:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 17:27:42 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v4]
In-Reply-To: <TLmxPztIA9GDXOK1UqlUFRvZzCLvf-6gWey7lHBZnsg=.f96033ff-bbd5-4a7b-b620-c748db76a012@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <kfLdZ6Yir4kIADj-EWWTXmpMcpOfn3wgYAhhWgteqrI=.af3f5472-9092-4dde-84fa-934408d4711d@github.com>
 <5KsawcB84bN5n-lTa6LQxDUPvJwPLAHmwHYOkAmoBVM=.8133d3cb-1c40-42b1-8f3f-17a3ecca7703@github.com>
 <XcRb4aJ2E-MZ6bZsddln48ia1VuVMdBeeobeWWo7hWg=.564d94e2-a139-4aa9-976b-dc709aaa6b60@github.com>
 <TLmxPztIA9GDXOK1UqlUFRvZzCLvf-6gWey7lHBZnsg=.f96033ff-bbd5-4a7b-b620-c748db76a012@github.com>
Message-ID: <4qZ-TU1ROueqnPO4OJzpmt97NtM3EVvaaV46ENmRu9U=.d320f195-dd7f-4f90-80ae-3ce3551d1aa9@github.com>

On Wed, 2 Oct 2024 17:23:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I think I need a reminder as to why we put values into these two fields when not available.
>> 
>> There's no reason to do so except to avoid testing availability.
>
> It still must test, in order to set the right value for the new available field.

I'll change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21274#discussion_r1784940339

From bpb at openjdk.org  Wed Oct  2 20:12:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 20:12:49 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v5]
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <KL0aJEWqmL-kJXPiphEamSqdkuDbT07MfR0y0HWWX1E=.fd9c6892-2471-4c2f-b886-71980ddc0167@github.com>

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

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

  8341282: On Linux, only set birthtime fields if available; fix macOS build failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21274/files
  - new: https://git.openjdk.org/jdk/pull/21274/files/4a4cde9b..5882b68b

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

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

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

From alanb at openjdk.org  Thu Oct  3 06:32:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Oct 2024 06:32:35 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v5]
In-Reply-To: <KL0aJEWqmL-kJXPiphEamSqdkuDbT07MfR0y0HWWX1E=.fd9c6892-2471-4c2f-b886-71980ddc0167@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <KL0aJEWqmL-kJXPiphEamSqdkuDbT07MfR0y0HWWX1E=.fd9c6892-2471-4c2f-b886-71980ddc0167@github.com>
Message-ID: <j6UviygmTG2PfUjELb_j7LfefuSbazFpG2ybvHMZi_g=.2a58f22f-a43b-4368-852e-be938036eff9@github.com>

On Wed, 2 Oct 2024 20:12:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: On Linux, only set birthtime fields if available; fix macOS build failure

Latest version looks okay to me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2344748987

From sgehwolf at openjdk.org  Thu Oct  3 08:13:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 08:13:36 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux) [v5]
In-Reply-To: <KL0aJEWqmL-kJXPiphEamSqdkuDbT07MfR0y0HWWX1E=.fd9c6892-2471-4c2f-b886-71980ddc0167@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
 <KL0aJEWqmL-kJXPiphEamSqdkuDbT07MfR0y0HWWX1E=.fd9c6892-2471-4c2f-b886-71980ddc0167@github.com>
Message-ID: <xkGQMF6CpHlIlo9geanjAjY4DUiCcHiy3SMwvkIvajM=.7c1fcbb6-400e-4b65-b06f-8fd872226f5c@github.com>

On Wed, 2 Oct 2024 20:12:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341282: On Linux, only set birthtime fields if available; fix macOS build failure

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21274#pullrequestreview-2344932717

From duke at openjdk.org  Thu Oct  3 08:55:36 2024
From: duke at openjdk.org (Jeremie Miserez)
Date: Thu, 3 Oct 2024 08:55:36 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <VrVrxKPgpH3FjsrxRKSB_a4MQsvMAYnPJYn3f5avNag=.ef844991-3d09-442e-94c0-50609d59c8b6@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

One more thing: I forgot to explain why the alias ISO-8859-8-i -> ISO-8859-8 would definitely be correct.

Java strings are stored in logical order. That is true for both LTR and RTL languages. This is plainly apparent from the OpenJDK String source code, but also explicitly mentioned/explained e.g. by official tutorials such as here: https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html#ordering_text

ISO-8859-8-i texts are always sent in logical order (by definition). **So decoding a ISO-8859-8-i text into a Java string using the ISO-8859-8 alias will result in the correct order of characters in the Java string, i.e. logical order, and thus is always 100% correct by definition.**

Technically speaking, and for completeness sake here is the full list of cases for regular ISO-8859-8 today:

1. ISO-8859-8 texts may contain either LTR language content, in which case the text is correctly decoded to a Java string in logical order. -> OK
2. ISO-8859-8 texts may also contain RTL language content in logical order (newer applications already do this), in which case the text is also correctly decoded to a Java string in logical order. -> OK (this is the case if the alias is added)
3. But: If a ISO-8859-8 text contains RTL language content in visual order (old applications, historically the case), the text would be decoded to a Java string in visual order. This is actually technically incorrect and may be a source of bugs (e.g. concatenation won't work correctly). However this behavior cannot be changed in OpenJDK anymore as (old) applications may rely on it.

So: As long as nobody adds a "auto-reverse visual to logical order" heuristic for RTL ISO-8859-8 text decoding in OpenJDK (which I'm fairly certain can't / mustn't be done), using a simple alias ISO-8859-8-i -> ISO-8859-8 will thus always be correct. The alias will result in case 2, i.e. texts will always be decoded into the correct Java string in logical order.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2390872037

From bpb at openjdk.org  Thu Oct  3 15:16:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Oct 2024 15:16:44 GMT
Subject: Integrated: 8341282: (fs) Move creation time fallback logic to Java
 layer (Linux)
In-Reply-To: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
References: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>
Message-ID: <v_ZcUDcJIf9g6hGzrcivUygim0ZnR3CCWo5BHDkDJzE=.04b7a60c-1ff1-4cef-9b43-abffce72f8f8@github.com>

On Mon, 30 Sep 2024 22:57:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

This pull request has now been integrated.

Changeset: 3ee94e04
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ee94e040a7395d11a294a6b660d707c97f188f8
Stats:     25 lines in 2 files changed: 12 ins; 6 del; 7 mod

8341282: (fs) Move creation time fallback logic to Java layer (Linux)

Reviewed-by: sgehwolf, alanb

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

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

From dhanalla at openjdk.org  Fri Oct  4 20:52:40 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Fri, 4 Oct 2024 20:52:40 GMT
Subject: Withdrawn: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
Message-ID: <OXPWJaEsrAbAaa5RgCjwlkFPveegTe5zk8y_bCilLKY=.36d4faf2-1446-4b98-9d8a-61246be6e7f9@github.com>

On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). 
> 
> This PR aims to replace these undocumented APIs with documented synchronization APIs. 
> 
> Test Performed:
> 1. All 12 tests in wepoll repo passed 
>            test-auto-drop-on-close PASS
>            test-connect-fail-events PASS
>            test-connect-success-events PASS
>            test-ctl-fuzz PASS
>            test-error PASS
>            test-leak-1 PASS
>            test-mixed-socket-types PASS
>            test-multi-poll PASS
>            test-oneshot-and-hangup PASS
>            test-reflock PASS
>            test-tree PASS
>            test-udp-pings PASS
>         DONE - 12 PASSED, 0 FAILED
> 
> 2. No new failure in JTreg test
> 3. Micro bench results: similar performance score before and after the changes
> 
> without change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c)
> 
> With the change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e)

This pull request has been closed without being integrated.

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

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

From syan at openjdk.org  Mon Oct  7 15:21:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 15:21:42 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <NcVxBg3n0vzoC0CDnwxEoSZqk3IJDDTEi3g0Ts5VN6w=.7f0e79c5-7de4-4933-937c-aab05d78d193@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

@AlanBateman Can you review this again, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2397226020

From bpb at openjdk.org  Mon Oct  7 16:04:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 7 Oct 2024 16:04:37 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <Z_xGWRNPB2bcfkasXdhLMQhEuA7wA8hroFRAxNijE0Q=.b6d118fe-d14f-439a-aa2a-9a33565af4a2@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>
 <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com>
 <Z_xGWRNPB2bcfkasXdhLMQhEuA7wA8hroFRAxNijE0Q=.b6d118fe-d14f-439a-aa2a-9a33565af4a2@github.com>
Message-ID: <wL__qhT5MLPT7ytdl9NrGkC0IXZ1g1Kx-dooh5oqOMQ=.7ca80c05-cb03-4a99-8d17-26d9366a6044@github.com>

On Fri, 13 Sep 2024 15:42:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.
>> 
>> @bplb Do you mean the updated one in this PR or the old one without this patch?
>
>> > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.
>> 
>> @bplb Do you mean the updated one in this PR or the old one without this patch?
> 
> @jerboaa The latest version in this PR.

> I don't have cycles right now but I'm sure @bplb can help.

It's now in my queue.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2397327693

From alanb at openjdk.org  Mon Oct  7 16:04:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Oct 2024 16:04:37 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <NcVxBg3n0vzoC0CDnwxEoSZqk3IJDDTEi3g0Ts5VN6w=.7f0e79c5-7de4-4933-937c-aab05d78d193@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <NcVxBg3n0vzoC0CDnwxEoSZqk3IJDDTEi3g0Ts5VN6w=.7f0e79c5-7de4-4933-937c-aab05d78d193@github.com>
Message-ID: <T5qRBC5liidn82JugHMrunDmFy59zrUnHbKvJMositU=.e8732d5a-a6f8-42d2-9ad3-963c9446e164@github.com>

On Mon, 7 Oct 2024 15:18:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> @AlanBateman Can you review this again, thanks.

I don't have cycles right now but I'm sure @bplb can help.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2397322144

From ihse at openjdk.org  Tue Oct  8 14:51:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 14:51:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <trKpuI8_8X3YZ1W6HJNNJYI3wbpLdkBbA49UUl9kvZU=.a1351ef4-30e3-4b9e-8df3-f97646592f97@github.com>

On Fri, 13 Sep 2024 20:41:27 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 incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

Build changes still look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2354745100

From bpb at openjdk.org  Tue Oct  8 18:39:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Oct 2024 18:39:03 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <ttm_oi0FGyLIDOtz3MP1mF97BrMVJpU3sLrAt1U5euQ=.348a0815-4086-44bd-b7f2-766291d1e425@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 125:

> 123:             FileTime current = creationTime(file);
> 124:             if (!current.equals(creationTime)) {
> 125:                 System.out.println("current = " + current);

I think it would be better to use `System.err` on these two lines, as was done at line 81.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 105:

> 103:     ret = my_statx_func(AT_FDCWD, file, atflag, mask, &stx);
> 104: 
> 105:     #ifdef DEBUG

This `DEBUG` block could be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792336418
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792337030

From bpb at openjdk.org  Tue Oct  8 18:44:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Oct 2024 18:44:00 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <kyvck8OWB4woTeOKtwy0n4RGjtDfcl4eUMQCasgsIhM=.025b3bf3-c85c-45a7-abef-2710ce3a7ffd@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

The test passed on Linux, macOS, and Windows in our internal test platform. I think after the two most recent points mentioned above are addressed it is good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2400569620

From syan at openjdk.org  Wed Oct  9 01:16:59 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 01:16:59 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v18]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <kFZfLgIIM_rorIen_NkVhttTGUqY9RfkbiZhmeTyLVc=.3ec27997-c3a5-4a6b-862d-c68f8355097d@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  1. delete #DEBUG block in test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c; 2. use System.err instead of System.out in test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/7a7916f4..6d4eb11a

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

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

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

From syan at openjdk.org  Wed Oct  9 01:17:00 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 01:17:00 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <ttm_oi0FGyLIDOtz3MP1mF97BrMVJpU3sLrAt1U5euQ=.348a0815-4086-44bd-b7f2-766291d1e425@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <ttm_oi0FGyLIDOtz3MP1mF97BrMVJpU3sLrAt1U5euQ=.348a0815-4086-44bd-b7f2-766291d1e425@github.com>
Message-ID: <SeWu4Hn4XoxZsnGqUoOIkqg5Ep0hRwHEmPyEka97pEo=.ab511bf5-15cb-4152-b182-07f905f1237c@github.com>

On Tue, 8 Oct 2024 18:35:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   initail struct stx var to zero
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 125:
> 
>> 123:             FileTime current = creationTime(file);
>> 124:             if (!current.equals(creationTime)) {
>> 125:                 System.out.println("current = " + current);
> 
> I think it would be better to use `System.err` on these two lines, as was done at line 81.

Thanks for the review. These two `System.out` has been replaced as `System.err`.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 105:
> 
>> 103:     ret = my_statx_func(AT_FDCWD, file, atflag, mask, &stx);
>> 104: 
>> 105:     #ifdef DEBUG
> 
> This `DEBUG` block could be removed.

`DEBUG` block has been removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792666449
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792666818

From syan at openjdk.org  Wed Oct  9 01:27:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 01:27:05 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <kyvck8OWB4woTeOKtwy0n4RGjtDfcl4eUMQCasgsIhM=.025b3bf3-c85c-45a7-abef-2710ce3a7ffd@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <kyvck8OWB4woTeOKtwy0n4RGjtDfcl4eUMQCasgsIhM=.025b3bf3-c85c-45a7-abef-2710ce3a7ffd@github.com>
Message-ID: <AG8PkdGZ4Nqn8ShR0BUJcbdUsiWeLHPR5St3zke3YT8=.ec2a51dc-7a06-45c0-a484-1bccb9ad0bcd@github.com>

On Tue, 8 Oct 2024 18:41:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The test passed on Linux, macOS, and Windows in our internal test platform. I think after the two most recent points mentioned above are addressed it is good to go.

Thanks for the verify and review. The two advices has been addressed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2401088563

From bpb at openjdk.org  Wed Oct  9 03:06:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 03:06:02 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v18]
In-Reply-To: <kFZfLgIIM_rorIen_NkVhttTGUqY9RfkbiZhmeTyLVc=.3ec27997-c3a5-4a6b-862d-c68f8355097d@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <kFZfLgIIM_rorIen_NkVhttTGUqY9RfkbiZhmeTyLVc=.3ec27997-c3a5-4a6b-862d-c68f8355097d@github.com>
Message-ID: <5G3rjvKJrm8K3vYQ_HOCQxXBKKEQbv9eMN4_FrAC_-k=.282455db-8b55-402c-b3ae-63b6548148be@github.com>

On Wed, 9 Oct 2024 01:16:59 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. delete #DEBUG block in test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c; 2. use System.err instead of System.out in test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 80:

> 78:         Instant now = Instant.now();
> 79:         if (Math.abs(creationTime.toMillis()-now.toEpochMilli()) > 10000L) {
> 80:             System.out.println("creationTime.toMillis() == " + creationTime.toMillis());

Sorry but would you please change line 80 to use `System.err` also? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792722644

From syan at openjdk.org  Wed Oct  9 06:01:21 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 06:01:21 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v19]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  Use System.err.println instead of System.out.println in line 80 of test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/6d4eb11a..a086f889

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

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

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

From syan at openjdk.org  Wed Oct  9 06:01:21 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 06:01:21 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v18]
In-Reply-To: <5G3rjvKJrm8K3vYQ_HOCQxXBKKEQbv9eMN4_FrAC_-k=.282455db-8b55-402c-b3ae-63b6548148be@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <kFZfLgIIM_rorIen_NkVhttTGUqY9RfkbiZhmeTyLVc=.3ec27997-c3a5-4a6b-862d-c68f8355097d@github.com>
 <5G3rjvKJrm8K3vYQ_HOCQxXBKKEQbv9eMN4_FrAC_-k=.282455db-8b55-402c-b3ae-63b6548148be@github.com>
Message-ID: <Z2rqI1C5B4_mu16D4Cdb1in1hq1hgnBLslxBlK7FJGc=.12268f3a-712c-4133-8e11-fbf45bd8746a@github.com>

On Wed, 9 Oct 2024 03:03:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. delete #DEBUG block in test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c; 2. use System.err instead of System.out in test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 80:
> 
>> 78:         Instant now = Instant.now();
>> 79:         if (Math.abs(creationTime.toMillis()-now.toEpochMilli()) > 10000L) {
>> 80:             System.out.println("creationTime.toMillis() == " + creationTime.toMillis());
> 
> Sorry but would you please change line 80 to use `System.err` also? Thanks.

Sorry for miss the replaced. The line 80 has been changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1792888234

From bpb at openjdk.org  Wed Oct  9 15:38:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 15:38:06 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v19]
In-Reply-To: <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
Message-ID: <57jCXwCxCMaOTGGeccAKRh6vXai1t0-6HMUdnTTubpc=.107c77aa-d628-40e1-80f5-c04c794e6702@github.com>

On Wed, 9 Oct 2024 06:01:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err.println instead of System.out.println in line 80 of test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

Looks all right now.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2357514934

From bpb at openjdk.org  Wed Oct  9 15:38:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 15:38:07 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v18]
In-Reply-To: <Z2rqI1C5B4_mu16D4Cdb1in1hq1hgnBLslxBlK7FJGc=.12268f3a-712c-4133-8e11-fbf45bd8746a@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <kFZfLgIIM_rorIen_NkVhttTGUqY9RfkbiZhmeTyLVc=.3ec27997-c3a5-4a6b-862d-c68f8355097d@github.com>
 <5G3rjvKJrm8K3vYQ_HOCQxXBKKEQbv9eMN4_FrAC_-k=.282455db-8b55-402c-b3ae-63b6548148be@github.com>
 <Z2rqI1C5B4_mu16D4Cdb1in1hq1hgnBLslxBlK7FJGc=.12268f3a-712c-4133-8e11-fbf45bd8746a@github.com>
Message-ID: <ltwW45f6DCFwzL5pf2yeMXIqP0ZkaLIPkXZthU7bjVY=.0bbd4e71-f65e-4125-93dd-9a0397389c4c@github.com>

On Wed, 9 Oct 2024 05:58:33 GMT, SendaoYan <syan at openjdk.org> wrote:

> Sorry for miss the replaced. The line 80 has been changed.

Thanks for the change. I approved it but you'll need one more (@jerboaa ).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1793744901

From sgehwolf at openjdk.org  Wed Oct  9 16:19:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Oct 2024 16:19:07 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v19]
In-Reply-To: <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
Message-ID: <-8BpeG8H0L2NX6cmmW4HluoabdWF2ZI2VBDYBBWbvKE=.a3c553f1-64c0-4aaf-8786-1932dbbce7d8@github.com>

On Wed, 9 Oct 2024 06:01:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err.println instead of System.out.println in line 80 of test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2357619496

From jlu at openjdk.org  Wed Oct  9 17:34:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 17:34:18 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
Message-ID: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>

Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.

This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

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

Commit messages:
 - init

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

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

From srl at openjdk.org  Wed Oct  9 17:49:03 2024
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 9 Oct 2024 17:49:03 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <J2dIcAmfXPbn_z7QNEvhMmyDQerKa-LB74cw2Lkzct0=.7037dcba-937c-4dcd-be69-609396781cb6@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

This is the right way to handle it.

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

Marked as reviewed by srl (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20690#pullrequestreview-2357809658

From srl at openjdk.org  Wed Oct  9 20:27:14 2024
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 9 Oct 2024 20:27:14 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <VrVrxKPgpH3FjsrxRKSB_a4MQsvMAYnPJYn3f5avNag=.ef844991-3d09-442e-94c0-50609d59c8b6@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <VrVrxKPgpH3FjsrxRKSB_a4MQsvMAYnPJYn3f5avNag=.ef844991-3d09-442e-94c0-50609d59c8b6@github.com>
Message-ID: <aq_sMHhlZch1HgL67hrb6OE3kV-2zf22kKKiL1tHcSA=.9c92bc4f-aeb6-411c-bae8-5dffe6191ff9@github.com>

On Thu, 3 Oct 2024 08:52:01 GMT, Jeremie Miserez <duke at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> One more thing: I forgot to explain why the alias ISO-8859-8-i -> ISO-8859-8 would definitely be correct.
> 
> Java strings are stored in logical order. That is true for both LTR and RTL languages. This is plainly apparent from the OpenJDK String source code, but also explicitly mentioned/explained e.g. by official tutorials such as here: https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html#ordering_text
> 
> ISO-8859-8-i texts are always sent in logical order (by definition). **So decoding a ISO-8859-8-i text into a Java string using the ISO-8859-8 alias will result in the correct order of characters in the Java string, i.e. logical order, and thus is always 100% correct by definition.**
> 
> Technically speaking, and for completeness sake here is the full list of cases for regular ISO-8859-8 today:
> 
> 1. ISO-8859-8 texts may contain either LTR language content, in which case the text is correctly decoded to a Java string in logical order. -> OK
> 2. ISO-8859-8 texts may also contain RTL language content in logical order (newer applications already do this), in which case the text is also correctly decoded to a Java string in logical order. -> OK.
> 3. But: If a ISO-8859-8 text contains RTL language content in visual order (old applications, historically the case), the text would be decoded to a Java string in visual order. This is actually technically incorrect and may be a source of bugs (e.g. concatenation won't work correctly). However this behavior cannot be changed in OpenJDK anymore as (old) applications may rely on it.
> 
> So: Case 2 is what would happen if the alias was added. Now as long as nobody adds a "auto-reverse visual to logical order" heuristic for RTL ISO-8859-8 text decoding in OpenJDK (which I'm fairly certain can't / mustn't be done), using a simple alias ISO-8859-8-i -> ISO-8859-8 will thus always be correct. The alias will result in case 2, i.e. texts will always be decoded into the correct Java string in logical order.

@jmiserez wrote:

> But: If a ISO-8859-8 text contains RTL language content in visual order (old applications, historically the case), the text would be decoded to a Java string in visual order. This is actually technically incorrect and may be a source of bugs (e.g. concatenation won't work correctly). However this behavior cannot be changed in OpenJDK anymore as (old) applications may rely on it.

In other words, Java _may_ have been incorrectly handling `ISO-8859-8` all this time if content was in visual order. Putting in this alias means that ISO-8859-8-I will be handled correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2403364716

From bpb at openjdk.org  Wed Oct  9 20:53:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 20:53:11 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <tqvIAkR2Pnq2kXud51IgHSTrvh1E-SSVvth9irzjQMI=.66c6029b-d254-419c-91bd-366cbae51166@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

I think this is correct. `ExceptionOccurred` returns a local reference to a `Throwable` but it is used only in an implicit `!= NULL` check which is better served by the `jboolean` returned by `ExceptionCheck`.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2358283754

From syan at openjdk.org  Thu Oct 10 01:08:27 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 10 Oct 2024 01:08:27 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v19]
In-Reply-To: <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <OY6wL34TY-pg8_ea6Yw445KmTXbFGOyK-x-JlEJoB5o=.fcb04d2a-260b-4cd5-abe8-76c8adfd1e5d@github.com>
Message-ID: <sjlFfHn9kNhuIAHnExwMITLnb8VpV5FEriNhsx8J4dU=.fa65f95e-0cad-4118-9231-82b78954b1b4@github.com>

On Wed, 9 Oct 2024 06:01:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.err.println instead of System.out.println in line 80 of test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2403693036

From syan at openjdk.org  Thu Oct 10 01:08:28 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 10 Oct 2024 01:08:28 GMT
Subject: Integrated: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <rWV1UO__AbCb4uzyexgvsQg3q7XWh4gw53o-PLBoU2o=.93280ccf-f991-44e1-9560-e7688431a0a0@github.com>

On Fri, 23 Aug 2024 03:58:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

This pull request has now been integrated.

Changeset: 9d621d39
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d621d3914b39cfdcda97274a7af5ca0fe062d35
Stats:     207 lines in 4 files changed: 189 ins; 7 del; 11 mod

8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3

Reviewed-by: sgehwolf, bpb

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

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

From duke at openjdk.org  Thu Oct 10 05:26:11 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Thu, 10 Oct 2024 05:26:11 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <VrVrxKPgpH3FjsrxRKSB_a4MQsvMAYnPJYn3f5avNag=.ef844991-3d09-442e-94c0-50609d59c8b6@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <VrVrxKPgpH3FjsrxRKSB_a4MQsvMAYnPJYn3f5avNag=.ef844991-3d09-442e-94c0-50609d59c8b6@github.com>
Message-ID: <EL--QCcN_nn5rxG25dpMPBtD1jE2YGfZVJYFiK0IFFc=.1cf123e1-d978-4fb3-9de5-2b668a405557@github.com>

On Thu, 3 Oct 2024 08:52:01 GMT, Jeremie Miserez <duke at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> One more thing: I forgot to explain why the alias ISO-8859-8-i -> ISO-8859-8 would definitely be correct.
> 
> Java strings are stored in logical order. That is true for both LTR and RTL languages. This is plainly apparent from the OpenJDK String source code, but also explicitly mentioned/explained e.g. by official tutorials such as here: https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html#ordering_text
> 
> ISO-8859-8-i texts are always sent in logical order (by definition). **So decoding a ISO-8859-8-i text into a Java string using the ISO-8859-8 alias will result in the correct order of characters in the Java string, i.e. logical order, and thus is always 100% correct by definition.**
> 
> Technically speaking, and for completeness sake here is the full list of cases for regular ISO-8859-8 today:
> 
> 1. ISO-8859-8 texts may contain either LTR language content, in which case the text is correctly decoded to a Java string in logical order. -> OK
> 2. ISO-8859-8 texts may also contain RTL language content in logical order (newer applications already do this), in which case the text is also correctly decoded to a Java string in logical order. -> OK.
> 3. But: If a ISO-8859-8 text contains RTL language content in visual order (old applications, historically the case), the text would be decoded to a Java string in visual order. This is actually technically incorrect and may be a source of bugs (e.g. concatenation won't work correctly). However this behavior cannot be changed in OpenJDK anymore as (old) applications may rely on it.
> 
> So: Case 2 is what would happen if the alias was added. Now as long as nobody adds a "auto-reverse visual to logical order" heuristic for RTL ISO-8859-8 text decoding in OpenJDK (which I'm fairly certain can't / mustn't be done), using a simple alias ISO-8859-8-i -> ISO-8859-8 will thus always be correct. The alias will result in case 2, i.e. texts will always be decoded into the correct Java string in logical order.

Thank you @jmiserez and @srl295 for the approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2404054401

From duke at openjdk.org  Thu Oct 10 05:33:11 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Thu, 10 Oct 2024 05:33:11 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <Na8UyyWw50w06OmA82DKBlPb8DafD4XTLbtI5bO4PTM=.2bd106b9-66de-44ac-be69-9c4a34425e8a@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <Na8UyyWw50w06OmA82DKBlPb8DafD4XTLbtI5bO4PTM=.2bd106b9-66de-44ac-be69-9c4a34425e8a@github.com>
Message-ID: <xeWOnQ5Fedd0n9ekmVLJUm1bTkdTxSZj7YusnWR80rA=.0ee7eef5-ac01-4a7c-8175-c13d72cd2264@github.com>

On Sun, 25 Aug 2024 07:21:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> I've added the "csr" label as this is adding support for "ISO8859-8-I".
> 
> Naoto asked me about it but I'm not 100% sure if it's an alias or a different charset. I think this topic may require input from those more familiar with charsets in environment that require bidi processing. Or if the mappings are available then I think we can see if they are identical to ISO8859-8.

@AlanBateman Since the mapping is just an alias to ISO-8859-8 do we still need CSR request to be created for the pull request?

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2404062521

From chagedorn at openjdk.org  Thu Oct 10 06:45:09 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 06:45:09 GMT
Subject: Integrated: 8341882: [BACKOUT]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
Message-ID: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>

[JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build failures on linux-x64 in tier1 in our CI:

[2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'linux-x64-debug' (exit code 2) 
[2024-10-10T01:31:30,298Z] 
[2024-10-10T01:31:30,298Z] === Output from failing command(s) repeated here ===
[2024-10-10T01:31:30,298Z] * For target support_test_jdk_jtreg_native_support_libCreationTimeHelper_libCreationTimeHelper.o:
[2024-10-10T01:31:30,298Z] In file included from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm/fcntl.h:1,
[2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/linux/fcntl.h:4,
[2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/slaves/7a20d425-e769-4142-b5c1-e3cc2d88e03e-S42674/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fd7e07c7-e1ac-4cf1-956e-1335b47d1afc/runs/eae3a102-cca9-477c-9539-3062f62476fa/workspace/open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:26:
[2024-10-10T01:31:30,298Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm-generic/fcntl.h:96:9: error: unknown type name 'pid_t'
[2024-10-10T01:31:30,298Z]    96 |         pid_t   pid;
[2024-10-10T01:31:30,298Z]       |         ^~~~~


Let's back this change out (pinging @sendaoYan). Revert was clean.

I created a [REDO](https://bugs.openjdk.org/browse/JDK-8341881).

Thanks,
Christian

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

Commit messages:
 - Revert "8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3"

Changes: https://git.openjdk.org/jdk/pull/21441/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21441&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341882
  Stats: 207 lines in 4 files changed: 7 ins; 189 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21441.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21441/head:pull/21441

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

From thartmann at openjdk.org  Thu Oct 10 06:45:12 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 06:45:12 GMT
Subject: Integrated: 8341882: [BACKOUT]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
References: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
Message-ID: <22IOIJtqogaAqkUfYibfGl9uqnNlSR8ooWpmdliCxMA=.4f3ffd8f-7777-4088-ba28-3a0d29fddf87@github.com>

On Thu, 10 Oct 2024 06:36:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build failures on linux-x64 in tier1 in our CI:
> 
> [2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'linux-x64-debug' (exit code 2) 
> [2024-10-10T01:31:30,298Z] 
> [2024-10-10T01:31:30,298Z] === Output from failing command(s) repeated here ===
> [2024-10-10T01:31:30,298Z] * For target support_test_jdk_jtreg_native_support_libCreationTimeHelper_libCreationTimeHelper.o:
> [2024-10-10T01:31:30,298Z] In file included from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm/fcntl.h:1,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/linux/fcntl.h:4,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/slaves/7a20d425-e769-4142-b5c1-e3cc2d88e03e-S42674/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fd7e07c7-e1ac-4cf1-956e-1335b47d1afc/runs/eae3a102-cca9-477c-9539-3062f62476fa/workspace/open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:26:
> [2024-10-10T01:31:30,298Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm-generic/fcntl.h:96:9: error: unknown type name 'pid_t'
> [2024-10-10T01:31:30,298Z]    96 |         pid_t   pid;
> [2024-10-10T01:31:30,298Z]       |         ^~~~~
> 
> 
> Let's back this change out (pinging @sendaoYan). Revert was clean.
> 
> I created a [REDO](https://bugs.openjdk.org/browse/JDK-8341881).
> 
> Thanks,
> Christian

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21441#pullrequestreview-2359144620

From chagedorn at openjdk.org  Thu Oct 10 06:45:14 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 06:45:14 GMT
Subject: Integrated: 8341882: [BACKOUT]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
References: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
Message-ID: <C1cXPgdmyufSccabXHy4w9NR-A6UwOSM8oppP-OrrFY=.28c41be1-1887-41bb-a26c-1015efa04be9@github.com>

On Thu, 10 Oct 2024 06:36:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build failures on linux-x64 in tier1 in our CI:
> 
> [2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'linux-x64-debug' (exit code 2) 
> [2024-10-10T01:31:30,298Z] 
> [2024-10-10T01:31:30,298Z] === Output from failing command(s) repeated here ===
> [2024-10-10T01:31:30,298Z] * For target support_test_jdk_jtreg_native_support_libCreationTimeHelper_libCreationTimeHelper.o:
> [2024-10-10T01:31:30,298Z] In file included from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm/fcntl.h:1,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/linux/fcntl.h:4,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/slaves/7a20d425-e769-4142-b5c1-e3cc2d88e03e-S42674/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fd7e07c7-e1ac-4cf1-956e-1335b47d1afc/runs/eae3a102-cca9-477c-9539-3062f62476fa/workspace/open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:26:
> [2024-10-10T01:31:30,298Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm-generic/fcntl.h:96:9: error: unknown type name 'pid_t'
> [2024-10-10T01:31:30,298Z]    96 |         pid_t   pid;
> [2024-10-10T01:31:30,298Z]       |         ^~~~~
> 
> 
> Let's back this change out (pinging @sendaoYan). Revert was clean.
> 
> I created a [REDO](https://bugs.openjdk.org/browse/JDK-8341881).
> 
> Thanks,
> Christian

Thanks Tobias for the quick review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21441#issuecomment-2404172263

From chagedorn at openjdk.org  Thu Oct 10 06:45:14 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 06:45:14 GMT
Subject: Integrated: 8341882: [BACKOUT]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
References: <owen3xn0wSWx3bKfWLQpQLbWTkmxsTsALPJikBXsF9M=.d8cfe997-998e-48ef-9d26-9fc319ee9a07@github.com>
Message-ID: <ovkYctegofwlsMB_GnVOAohsAzTCIgTbQfXh7yM3rm8=.7874970a-50b3-4c82-80f4-4b63ce82fd15@github.com>

On Thu, 10 Oct 2024 06:36:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build failures on linux-x64 in tier1 in our CI:
> 
> [2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default (product-bundles test-bundles static-libs-bundles)' in configuration 'linux-x64-debug' (exit code 2) 
> [2024-10-10T01:31:30,298Z] 
> [2024-10-10T01:31:30,298Z] === Output from failing command(s) repeated here ===
> [2024-10-10T01:31:30,298Z] * For target support_test_jdk_jtreg_native_support_libCreationTimeHelper_libCreationTimeHelper.o:
> [2024-10-10T01:31:30,298Z] In file included from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm/fcntl.h:1,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/linux/fcntl.h:4,
> [2024-10-10T01:31:30,298Z]                  from /opt/mach5/mesos/work_dir/slaves/7a20d425-e769-4142-b5c1-e3cc2d88e03e-S42674/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fd7e07c7-e1ac-4cf1-956e-1335b47d1afc/runs/eae3a102-cca9-477c-9539-3062f62476fa/workspace/open/test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c:26:
> [2024-10-10T01:31:30,298Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64/gcc13.2.0-OL6.4+1.0/devkit-linux_x64-gcc13.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/x86_64-linux-gnu/sysroot/usr/include/asm-generic/fcntl.h:96:9: error: unknown type name 'pid_t'
> [2024-10-10T01:31:30,298Z]    96 |         pid_t   pid;
> [2024-10-10T01:31:30,298Z]       |         ^~~~~
> 
> 
> Let's back this change out (pinging @sendaoYan). Revert was clean.
> 
> I created a [REDO](https://bugs.openjdk.org/browse/JDK-8341881).
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 36fca5d1
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36fca5d19d6c0eb0391b4a36db689d9c3aae09b1
Stats:     207 lines in 4 files changed: 7 ins; 189 del; 11 mod

8341882: [BACKOUT] java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3

Reviewed-by: thartmann

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

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

From jpai at openjdk.org  Thu Oct 10 07:06:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Oct 2024 07:06:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <nmKLk2D_1pr_O5549B-2Hr9qmQ8gV3xEkaeX0QWkBZY=.bde04ae3-e5dc-4d5c-961e-ec205d1e92f0@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359224533

From duke at openjdk.org  Thu Oct 10 09:27:12 2024
From: duke at openjdk.org (davecrighton)
Date: Thu, 10 Oct 2024 09:27:12 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
Message-ID: <1a0vi_w0Eic3g2F10GXKJU1D96oJ5f_u7tftk7W63Rg=.c34dc86a-c679-4082-bbb6-32884407210a@github.com>

On Mon, 16 Sep 2024 17:40:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

@naotoj In light of @jmiserez and @psawant19 's comments does this change the position of the openjdk team? 

We are interested as we are currently maintaining a fork of Jakarta mail in order to allow our customers to use this charset and would like to limit the amount of time we need to do this for.

For what it is worth our customer has deployed this into production and is successfully processing ISO-8859-8-i without any complaints from users.

Appreciate your work on reviewing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2390781177

From dfuchs at openjdk.org  Thu Oct 10 09:34:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Oct 2024 09:34:12 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <l6fjqVOKleomHN1GWHa9hd9GQdGgnNgqCwveUkwWr-c=.4c0e08a8-cd42-43ee-b0d1-4d05c439f527@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by dfuchs (Reviewer).

>From https://docs.oracle.com/en/java/javase/23/docs/specs/jni/functions.html#exceptioncheck :

> ExceptionCheck
> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
> 
> jboolean ExceptionCheck(JNIEnv *env);
> 
> Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.
> 

So this looks good to me too.

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

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359643144
PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404578043

From lancea at openjdk.org  Thu Oct 10 11:10:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 11:10:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Hi Justin,

Overall looks fine.  I
t looks like
open/src/java.base/share/native/libzip/Deflater.c
open/src/java.base/share/native/libzip/Inflater.c

also same for line 670 in open.bk/src/java.base/share/native/libjli/java.c

were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional

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

Changes requested by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359952631

From srl at openjdk.org  Thu Oct 10 11:12:12 2024
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 10 Oct 2024 11:12:12 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
Message-ID: <zcfbc61xnHJCojgqcjoU4GJBOkKBbnXWuKvuK9BzppY=.b847e4fe-025e-45f6-84bf-a4bc671ea53e@github.com>

On Mon, 16 Sep 2024 17:40:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

@naotoj does it make sense?

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2404797795

From alanb at openjdk.org  Thu Oct 10 11:43:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 11:43:12 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
 <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
Message-ID: <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>

On Thu, 10 Oct 2024 11:07:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional

The original bug report has several false positives, it flagged cases where ExceptionOccurred == NULL, which aren't issues. Some of these could be changed to ExceptionCheck to avoid create the throwable, that would be more about performance for exception cases so not too interesting.

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

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404860955

From lancea at openjdk.org  Thu Oct 10 12:09:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 12:09:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <xraZZW8sqoQZ77xsDds5MG0YSFOFhBZsukZW8BNqyDE=.67fb2364-59e7-4981-ab85-0dae74544648@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by lancea (Reviewer).

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360103431
PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360105737

From lancea at openjdk.org  Thu Oct 10 12:09:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 12:09:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
 <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
 <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>
Message-ID: <T6nDjqBNIbDKj4hbhHt9aOABFndPQChTtBfdE38wGKk=.08cf5ab5-a8c3-4c90-8e3a-c80a56227b3b@github.com>

On Thu, 10 Oct 2024 11:40:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional
> 
> The original bug report has several false positives, it flagged cases where ExceptionOccurred == NULL, which aren't issues. Some of these could be changed to ExceptionCheck to avoid create the throwable, that would be more about performance for exception cases so not too interesting.

Thanks for the clarification, I missed the comment you added to the bug

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

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404909070

From rriggs at openjdk.org  Thu Oct 10 13:52:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 13:52:11 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <MrmyaL7Vt13nMPINZRyqq1oVi6y4p1we3TgVNMS4psM=.4fad2ec5-65b2-4be3-af22-1e5d935f9f69@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360414401

From naoto at openjdk.org  Thu Oct 10 16:14:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Oct 2024 16:14:19 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <Oyzx743ZfHVD8v5ljUfSaMZDPbXtABeKWwTR1bNUKzg=.f91fe553-0810-4855-97f3-dd4f13beeb6a@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360837181

From naoto at openjdk.org  Thu Oct 10 16:35:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Oct 2024 16:35:17 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
Message-ID: <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>

On Mon, 16 Sep 2024 17:40:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

> @naotoj does it make sense?

Sorry, but I still don't believe that making "ISO-8859-8-I" as an alias to "ISO-8859-8" is the right solution, per the IANA character sets definition (https://www.iana.org/assignments/character-sets/character-sets.xhtml). The current PR would make "ISO-8859-8-I" charset appear in `Charset.forName("ISO-8859-8").aliases()`, but not in `Charset.availableCharsets()` which is deemed incorrect to me.

That said, I just wonder if this issue can better be addressed exploiting the Charset SPI. This way mail servers can install "ISO-8859-8-I" charset by themselves. This means that mail servers do not need to rely on the underlying JDK which may or may not have that charset.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2405570637

From jlu at openjdk.org  Thu Oct 10 16:54:13 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 16:54:13 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
 <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>
Message-ID: <-DjN1fRFZ_uqEg42BUUWDQYNCA6KSy54prw9sTniDaE=.9bf3d80d-3365-4f70-abaa-890125e1cf9c@github.com>

On Thu, 10 Oct 2024 16:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Sorry, but I still don't believe that making "ISO-8859-8-I" as an alias to "ISO-8859-8" is the right solution, per the IANA character sets definition (https://www.iana.org/assignments/character-sets/character-sets.xhtml). The current PR would make "ISO-8859-8-I" charset appear in `Charset.forName("ISO-8859-8").aliases()`, but not in `Charset.availableCharsets()` which is deemed incorrect to me.


I agree. From the Charset specification,

> If a charset listed in the IANA Charset Registry is supported by an implementation of the Java platform then its canonical name must be the name listed in the registry. Many charsets are given more than one name in the registry, in which case the registry identifies one of the names as MIME-preferred. If a charset has more than one registry name then its canonical name must be the MIME-preferred name and the other names in the registry must be valid aliases.

Practically speaking it does seem to be a alias, but implementing as such would violate the Charset specification. So either defining as a new Charset for ISO-8859-8-I (if there is sufficient demand) or as Naoto pointed out, utilize the CharsetProvider would seem like appropriate solutions to me. A pro to the SPI solution is that you can also easily include all the other bidi supported implicit/explicit Charsets as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2405607186

From jlu at openjdk.org  Thu Oct 10 17:36:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:18 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <y5ySdUaHq077MHmFPHWwYzgwKgIA1Ajs90h2TpYOMps=.cb3c434c-f069-4c8b-84d4-b862ede962af@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Thank you all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2405681457

From jlu at openjdk.org  Thu Oct 10 17:36:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:19 GMT
Subject: Integrated: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <1JyoGUOO4Ps9U46odRSiK9XlfgLMs7hpaNyXQY90W44=.c59cf882-36d8-4663-b728-6b6327a7ef86@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

This pull request has now been integrated.

Changeset: 7eb55357
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7eb55357ab169c21dd5d0ed1738155e794e5faaf
Stats:     34 lines in 10 files changed: 0 ins; 0 del; 34 mod

8341789: Fix ExceptionOccurred in java.base

Reviewed-by: bpb, jpai, dfuchs, lancea, rriggs, naoto

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

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

From srl at openjdk.org  Thu Oct 10 19:54:14 2024
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 10 Oct 2024 19:54:14 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <26-Z3D3phs2aXAMjJtUxTsB4EZFvpBrsks3iAcmxyjE=.e7bf9689-fa6e-4d6b-8094-3d734e63969b@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

Fair enough and feel free to reject my review if need be. 

It seems like from an API perspective, you are both saying it should be a new Charset provider (though with identical behavior) but separate and not an alias. That preserves the invariant about IANA registration.

It does still seem that the JDK is probably currently treating ISO-8859-8 as if it were ISO-8859-8-I.  I wonder why the implementation was done the way it is, but that?s only of historical interest.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2405915757

From syan at openjdk.org  Fri Oct 11 03:20:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 11 Oct 2024 03:20:29 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
Message-ID: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>

Hi all,
On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.

Additional testing:

- [x] build and test on alinux3
- [x] compile libCreationTimeHelper.c in centos6 docker container

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

Commit messages:
 - 8341881: [REDO] java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3

Changes: https://git.openjdk.org/jdk/pull/21462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341881
  Stats: 212 lines in 4 files changed: 194 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21462/head:pull/21462

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

From liach at openjdk.org  Fri Oct 11 04:13:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 04:13:12 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <8ZQlH98zFlo7m7eBx5nqP2LiCobi-tcDW7XDDD6WPAw=.bf2d5384-3734-4763-990d-5ea59298f3cb@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

This updated test runs fine in an OracleJDK setup that can reproduce the previous crash. Submitted internal tests for this patch and I anticipate this to pass.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21462#pullrequestreview-2361922784

From liach at openjdk.org  Fri Oct 11 04:46:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 04:46:10 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <XjXVg4Xq-5sWjDesdSxJgIN_CguyucKDSTfpdEfV_Lo=.c0b2e308-9647-4b80-a3b6-0bf0bd7ed7b8@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Build and tier 1 jobs for Linux pass on Oracle's internal CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2406544377

From syan at openjdk.org  Fri Oct 11 05:56:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 11 Oct 2024 05:56:09 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <XjXVg4Xq-5sWjDesdSxJgIN_CguyucKDSTfpdEfV_Lo=.c0b2e308-9647-4b80-a3b6-0bf0bd7ed7b8@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
 <XjXVg4Xq-5sWjDesdSxJgIN_CguyucKDSTfpdEfV_Lo=.c0b2e308-9647-4b80-a3b6-0bf0bd7ed7b8@github.com>
Message-ID: <c4ZAv4-E_YsF4mALVL0PWZwxGNUdUBsYS-11Q8kM7KY=.fa7a9dc4-bdbb-4325-bd55-a9ab0e3b26b9@github.com>

On Fri, 11 Oct 2024 04:43:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> Build and tier 1 jobs for Linux pass on Oracle's internal CI.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2406602280

From eirbjo at openjdk.org  Fri Oct 11 08:25:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 08:25:43 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
Message-ID: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>

Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.

These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):


// Override fill() method to provide an extra "dummy" byte
// at the end of the input stream. This is required when
// using the "nowrap" Inflater option.
protected void fill() throws IOException {

However, zlib has not required such an extra dummy byte since 2003. 


Changes in 1.2.0 (9 March 2003)
- New and improved inflate code
    - Raw inflate no longer needs an extra dummy byte at end
``` 

The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.

Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.

Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR.

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

Commit messages:
 - Remove overrides of InflaterInputStream.fill which provide an extra dummy byte at the end of raw compressed streams

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

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

From eirbjo at openjdk.org  Fri Oct 11 08:25:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 08:25:43 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <F_QzSn_a3Cn4uso-ERJKsp-aqq_SXueUTbEy1q87AAI=.eb52e277-c118-486c-abb2-9e36ec71723d@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR.

Channeling @simonis for his experience with third-party zlib implementations.

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

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2406875243

From sgehwolf at openjdk.org  Fri Oct 11 08:51:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 11 Oct 2024 08:51:12 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <wlwrUB8DoqoDg2fpzSY7n0hG4wueLvJ9_wz6ejAAdAU=.584f36ba-018c-4792-b91b-56aa5cb39b33@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Seems fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21462#pullrequestreview-2362293125

From syan at openjdk.org  Fri Oct 11 08:54:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 11 Oct 2024 08:54:09 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <CiRsOx7sONRmWj8XDrmIR8xRVCBj77iZRD8NHqKqjGk=.356bafda-10aa-41d8-9c4a-3589a4ed60a9@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2406942314

From duke at openjdk.org  Fri Oct 11 13:39:22 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 11 Oct 2024 13:39:22 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <-DjN1fRFZ_uqEg42BUUWDQYNCA6KSy54prw9sTniDaE=.9bf3d80d-3365-4f70-abaa-890125e1cf9c@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
 <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>
 <-DjN1fRFZ_uqEg42BUUWDQYNCA6KSy54prw9sTniDaE=.9bf3d80d-3365-4f70-abaa-890125e1cf9c@github.com>
Message-ID: <DWoogmbnyfdoBsv0kIR5MYdbVf3R24Wb9hKpGD39Tbk=.80cb9400-f5bd-4e42-9d4d-8e0b8ff98cfc@github.com>

On Thu, 10 Oct 2024 16:51:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>...(if there is sufficient demand)...

I don't fully understand the conditional acceptance.  Can't @psawant19 abandon the alias PR and use the existing ISO-8859-8 source from OpenJDK to create new ISO-8859-8-I Charset? The level off effort to share common code, proxy wrap, or so forth between two Charsets wouldn't be that much of a lift or long term debt.  If the community is willing to to the work then acceptance is really a willingness to approve the change.  Are all housed OpenJDK solutions around this a no?

>Naoto pointed out, utilize the CharsetProvider would seem like appropriate solutions to me. 

That has been the solution suggested for years.  They have been documented JavaMail/JakartaMail FAQ.  I copied them into the ticket here:
https://github.com/eclipse-ee4j/angus-mail/issues/147#issuecomment-2354433380

I'll leave that AngusMail ticket open until this comes to a close.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2407433620

From srl at openjdk.org  Fri Oct 11 13:44:18 2024
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 11 Oct 2024 13:44:18 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <xeWOnQ5Fedd0n9ekmVLJUm1bTkdTxSZj7YusnWR80rA=.0ee7eef5-ac01-4a7c-8175-c13d72cd2264@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <Na8UyyWw50w06OmA82DKBlPb8DafD4XTLbtI5bO4PTM=.2bd106b9-66de-44ac-be69-9c4a34425e8a@github.com>
 <xeWOnQ5Fedd0n9ekmVLJUm1bTkdTxSZj7YusnWR80rA=.0ee7eef5-ac01-4a7c-8175-c13d72cd2264@github.com>
Message-ID: <WTViL1x63ktyq5CS48-yKY9q4jnB0E9vj9_EqfWjrZI=.d1655ee1-29d4-4f0a-9927-176459762fd2@github.com>

On Thu, 10 Oct 2024 05:30:41 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

>> I've added the "csr" label as this is adding support for "ISO8859-8-I".
>> 
>> Naoto asked me about it but I'm not 100% sure if it's an alias or a different charset. I think this topic may require input from those more familiar with charsets in environment that require bidi processing. Or if the mappings are available then I think we can see if they are identical to ISO8859-8.
>
> @AlanBateman Since the mapping is just an alias to ISO-8859-8 do we still need CSR request to be created for the pull request?

> Can't @psawant19 abandon the alias PR and use the existing ISO-8859-8 source from OpenJDK to create new ISO-8859-8-I Charset?

That would seem to be what @naotoj stated would make the API contract (concerning IANA identity) correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2407442345

From lancea at openjdk.org  Fri Oct 11 14:08:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Oct 2024 14:08:09 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

I think we need to be a bit cautious with the proposed change while I understand the desire to remove potentially unneeded code. 

 I have not yet found a specific issue for the for the original need for the overload of fill, but have not looked to hard either, and the constructor in Inflater.java also makes reference to gzip for which we do not have as much test coverage as we do for Zip.

So we might want to hold off on this PR for JDK 24 while we try to do some more archaeological digging.

As far as which zlib with the openJDK,  currently the openjdk project bundles zlib with the windows builds and relies on the zlib bundled with the various OS's 

I would be surprised to find any vendor using a zlib below zlib 1.2.13 or 1.3.1

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

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407490236

From ihse at openjdk.org  Fri Oct 11 14:27:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Oct 2024 14:27:15 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <z3JOUkZHHU-u9kyrN78VLzgIbGhbglDZoExlLpx54Tc=.a684acc7-f76f-48f5-9407-e8d01d2272e1@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Build changes look fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21462#pullrequestreview-2362940203

From eirbjo at openjdk.org  Fri Oct 11 14:39:10 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 14:39:10 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate
In-Reply-To: <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
 <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>
Message-ID: <XTzzNDqSwpJdeDbK_Bz3C3AgTTMwYqIjxf1RHLCsFJw=.02a19a97-a4f3-479a-a056-c64736638d6a@github.com>

On Fri, 11 Oct 2024 14:05:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think we need to be a bit cautious with the proposed change while I understand the desire to remove potentially unneeded code.

I understand the need to be cautious in this area. But I would also like to avoid cargo-culting this for another 21 years :-)  

> I have not yet found a specific issue for the for the original need for the overload of fill, but have not looked to hard either

If we trust the zlib change log, the original need retired with 1.2.0. Any of the performance-motivated forks like chromium-zlib or cloudflare-zlib should have been forked long after this. Perhaps @simonis can confirm. 

>, and the constructor in Inflater.java also makes reference to gzip for which we do not have as much test coverage as we do for Zip.

It's interesting that `GZIPInputStream` does _not_ override `InflaterInputStream.fill`, but _does_ use `nowrap`.

The extra dummy byte note in the Inflater constructor is now misleading and should probably go too. Would require a CSR. 

The `@param nowrap` note is perhaps also misleading in that it is not actually specific to GZIP. It just tells zlib to expect raw deflated data, without any wrapping, GZIP or zlib. I guess since the only wrapping supported by the JDK is GZIP, the note is maybe okay. But if we do a CSR, I think we should relax this note to not reference GZIP.  

> So we might want to hold off on this PR for JDK 24 while we try to do some more archaeological digging.

That is fair.

> As far as which zlib with the openJDK, currently the openjdk project bundles zlib with the windows builds and relies on the zlib bundled with the various OS's
> 
> I would be surprised to find any vendor using a zlib below zlib 1.2.13 or 1.3.1

Yes, that would indeed be awkward.

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

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407549193

From liach at openjdk.org  Fri Oct 11 14:39:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 14:39:13 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <OXoko8EdaCEkdFNA1Vl71zuLsJS2WvSqNypjmWLweTA=.fb3e6586-45f3-46d9-b449-2dd7d2949141@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

I hope we have an nio area engineer such as @bplb to review this too.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2407553237

From eirbjo at openjdk.org  Fri Oct 11 15:16:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 15:16:50 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate [v2]
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update Inflater and Deflater constructors taking 'nowrap' options to explain more clearly what this option does

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21467/files
  - new: https://git.openjdk.org/jdk/pull/21467/files/661032c8..66abb0dc

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

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

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

From eirbjo at openjdk.org  Fri Oct 11 15:16:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 15:16:50 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <FfoWevKDqCL7NwhkZylNzwOSbPcRPf0_btWstfgUGBw=.dcf6aedb-a6b2-47d9-8dee-2ab50b0012e3@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

I have updated the `nowrap` constructor of `java.util.zip.Inflater` to remove the note about the extra 'dummy' input byte. I also tightened up the constructor to more clearly explain what the `nowrap` parameter does. The current "will not use" feels a bit loose. The `nowrap` parameter description is updated to not mention GZIP and instead just say "expect compressed input without ZLIB headers".

The matching constructor in `java.util.zip.Deflater` is updated to be consistent with the changes in `Inflater`. These should be easy to read side-by-side.

These API changes requires a CSR, which I plan to create once "more archaeological digging" deems this PR can continue safely.

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

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407618033

From bpb at openjdk.org  Fri Oct 11 15:41:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 11 Oct 2024 15:41:11 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <OXoko8EdaCEkdFNA1Vl71zuLsJS2WvSqNypjmWLweTA=.fb3e6586-45f3-46d9-b449-2dd7d2949141@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
 <OXoko8EdaCEkdFNA1Vl71zuLsJS2WvSqNypjmWLweTA=.fb3e6586-45f3-46d9-b449-2dd7d2949141@github.com>
Message-ID: <KYEa4-aFlo-i-hP4jUhJLR9nvilz6iQfbanMAHImaAw=.1f8df858-0a15-4647-9f99-7a660964d6c7@github.com>

On Fri, 11 Oct 2024 14:37:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
>> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
>> 
>> Additional testing:
>> 
>> - [x] build and test on alinux3
>> - [x] compile libCreationTimeHelper.c in centos6 docker container
>
> I hope we have an nio area engineer such as @bplb to review this too.

@liach Message received.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2407670300

From duke at openjdk.org  Fri Oct 11 15:58:18 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 11 Oct 2024 15:58:18 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
 <_D2pL8nWe_zvy9it7p3BPHisqkgcLAlAz4FXAX7m3iA=.106bd9a1-b765-4a0e-b224-58c66c4eba8a@github.com>
Message-ID: <vZb5vDaoQhWxoffRIo54g0aRVpGUu1g1fGIroa19Hho=.407fc625-10ad-4fa8-9367-274f21405714@github.com>

On Thu, 10 Oct 2024 16:32:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)
>
>> @naotoj does it make sense?
> 
> Sorry, but I still don't believe that making "ISO-8859-8-I" as an alias to "ISO-8859-8" is the right solution, per the IANA character sets definition (https://www.iana.org/assignments/character-sets/character-sets.xhtml). The current PR would make "ISO-8859-8-I" charset appear in `Charset.forName("ISO-8859-8").aliases()`, but not in `Charset.availableCharsets()` which is deemed incorrect to me.
> 
> That said, I just wonder if this issue can better be addressed exploiting the Charset SPI. This way mail servers can install "ISO-8859-8-I" charset by themselves. This means that mail servers do not need to rely on the underlying JDK which may or may not have that charset.

> That would seem to be what @naotoj stated would make the API contract (concerning IANA identity) correct.

Correct. I gathered that point. What I was trying to convey is that the contribution of the intellectual property is from OpenJDK itself so there is proven track record of quality of the code. 

Alias route is dead, done, rejected. Rejecting a PR on that route that is a 'clone of another charset' is either compatiblely concern or a unwillingness to accept the new charset.

Just trying to find a path forward on this.  Thus my intent is to figure out why charset approach would be rejected on the grounds that ISO-8859-8-I is "obsolete", does not have "sufficient demand", or is not "important" enough.  These are reject words sprinked in thread.

Contributors are here to help out work on this. Working on obsolete, unpopular, unimportant stuff is what we do sometimes.  We just need direction.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2407697259

From srl at openjdk.org  Fri Oct 11 16:02:14 2024
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 11 Oct 2024 16:02:14 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <efIgVp8nMkx3PqIh8Czc7HJLA_qeHfxSi6Hrf3B_Ui0=.a43c5012-6eae-4632-8009-bae137e227a0@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

I noticed that the embedded xerces treates 8859-8-I as 8859-8 here:

- https://github.com/openjdk/jdk/blob/7276a1bec0d90f63e9e433fdcdfd6564b70dc9bb/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2407704270

From bpb at openjdk.org  Fri Oct 11 17:09:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 11 Oct 2024 17:09:11 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <363epoCuH8MsRl0O4bumGq1MlMpOyRGtKf_KDDKwwY4=.4d4afb88-bc31-4950-8b03-e8a329503175@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

> This PR is a REDO PR of #20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.

The diff of diffs is this:

> @@ -0,0 +1,122 @@
202d201
< +#include <linux/fcntl.h>
216a216,221
> +#ifndef AT_SYMLINK_NOFOLLOW
> +#define AT_SYMLINK_NOFOLLOW 0x100
> +#endif
> +#ifndef AT_FDCWD
> +#define AT_FDCWD -100
> +#endif


> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.

In progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2407812101

From bpb at openjdk.org  Fri Oct 11 19:09:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 11 Oct 2024 19:09:11 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <QaZ6FelsQLnz3qEjhY-q04nHs4ODlQrYbefsJPpTLUE=.c428bb3d-5c29-4a50-928e-997b6dd26740@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Test passed on Linux-{aarch64,x64}, macOS-{aarch64,x64}, Windows-x64.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21462#pullrequestreview-2363419484

From syan at openjdk.org  Sat Oct 12 01:38:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 12 Oct 2024 01:38:19 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <QaZ6FelsQLnz3qEjhY-q04nHs4ODlQrYbefsJPpTLUE=.c428bb3d-5c29-4a50-928e-997b6dd26740@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
 <QaZ6FelsQLnz3qEjhY-q04nHs4ODlQrYbefsJPpTLUE=.c428bb3d-5c29-4a50-928e-997b6dd26740@github.com>
Message-ID: <QRMaZbPQi9XZm7vDGxSMp3o-yK_FqfkpMmwXuZeC4H0=.383335a6-d5d3-4396-a901-87d3b63392d9@github.com>

On Fri, 11 Oct 2024 19:06:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Test passed on Linux-{aarch64,x64}, macOS-{aarch64,x64}, Windows-x64.

Thanks for the verify very much.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2408291098

From varadam at openjdk.org  Mon Oct 14 07:13:45 2024
From: varadam at openjdk.org (Varada M)
Date: Mon, 14 Oct 2024 07:13:45 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
Message-ID: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>

Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)

Ran the test for 50 times and didn't observed any timeout error.
Tier 1 testing successful with fastdebug VM

JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)

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

Commit messages:
 - Merge branch 'master' into stressloopback
 - JDK-8211851: (ch) java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)

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

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

From alanb at openjdk.org  Mon Oct 14 07:22:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Oct 2024 07:22:14 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
In-Reply-To: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
Message-ID: <VtEVqT1Wl21-TiULoQ0mzUirQQ-i4P284OJrgluFk_A=.3c73fa44-2255-45f5-a066-b24020bce8f4@github.com>

On Mon, 14 Oct 2024 07:08:36 GMT, Varada M <varadam at openjdk.org> wrote:

> Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)
> 
> Ran the test for 50 times and didn't observed any timeout error.
> Tier 1 testing successful with fastdebug VM
> 
> JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)

src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 228:

> 226:     @Override
> 227:     void startPoll(int fd, int events) {
> 228:         // update events (or add to epoll on first usage)

I assume you didn't mean to say "epoll" in this comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21487#discussion_r1798882739

From varadam at openjdk.org  Mon Oct 14 10:03:55 2024
From: varadam at openjdk.org (Varada M)
Date: Mon, 14 Oct 2024 10:03:55 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
Message-ID: <4ZuupXOgZBT9kSv6STF4Rw_xBf4SmmsyOCeT4MtP7DY=.388a6220-573f-457a-a6df-82c3e5198b11@github.com>

> Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)
> 
> Ran the test for 50 times and didn't observed any timeout error.
> Tier 1 testing successful with fastdebug VM
> 
> JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)

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

  8211851: (ch) java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21487/files
  - new: https://git.openjdk.org/jdk/pull/21487/files/082b0705..62f92507

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

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

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

From varadam at openjdk.org  Mon Oct 14 10:03:55 2024
From: varadam at openjdk.org (Varada M)
Date: Mon, 14 Oct 2024 10:03:55 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <VtEVqT1Wl21-TiULoQ0mzUirQQ-i4P284OJrgluFk_A=.3c73fa44-2255-45f5-a066-b24020bce8f4@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
 <VtEVqT1Wl21-TiULoQ0mzUirQQ-i4P284OJrgluFk_A=.3c73fa44-2255-45f5-a066-b24020bce8f4@github.com>
Message-ID: <s6-cUpqc9plG2OkAYUg-uXSDgJuihtGmOjxdOpCNvgU=.0234f3f2-93eb-439f-9ff9-b7eb5834dde7@github.com>

On Mon, 14 Oct 2024 07:19:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Varada M has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8211851: (ch) java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)
>
> src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 228:
> 
>> 226:     @Override
>> 227:     void startPoll(int fd, int events) {
>> 228:         // update events (or add to epoll on first usage)
> 
> I assume you didn't mean to say "epoll" in this comment.

Thanks for the pointing that out. Fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21487#discussion_r1799120291

From syan at openjdk.org  Mon Oct 14 12:35:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 14 Oct 2024 12:35:20 GMT
Subject: RFR: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <_Td01raY5NkSSua2YdIP7oIJ44hssbBarRQLclR0FVk=.ad455a0c-84fe-43d2-8dc8-8630fbd92ef8@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21462#issuecomment-2411100191

From syan at openjdk.org  Mon Oct 14 12:35:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 14 Oct 2024 12:35:22 GMT
Subject: Integrated: 8341881: [REDO]
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
References: <L1gxqhc1wadG_3Qhwjg8Ov_Und6M7C1gb4TTgFSIAbE=.370b26bd-5198-4e8e-8fd5-cbdd1a5605a2@github.com>
Message-ID: <KjCmqiW1TflxFHETSD3Tzjmcs2zR_39HY6plk4wBokQ=.1b86bfd0-9c42-4d60-901d-4f8f531d5b46@github.com>

On Fri, 11 Oct 2024 03:14:40 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the /tmp disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> This PR is a REDO PR of https://github.com/openjdk/jdk/pull/20687, the diffrent is delete `#include <linux/fcntl.h>` and add `#define AT_SYMLINK_NOFOLLOW 0x100` `#define AT_FDCWD -100`, because the linux header `<linux/fcntl.h>` file can't work on centos6.
> If anyone at Oracle can help me verify this PR, which include build and jtreg tier1 test, I will be quite appreciate for that.
> 
> Additional testing:
> 
> - [x] build and test on alinux3
> - [x] compile libCreationTimeHelper.c in centos6 docker container

This pull request has now been integrated.

Changeset: f56a1541
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f56a154132f7e66b1b65adfa2aa937119999b14a
Stats:     212 lines in 4 files changed: 194 ins; 7 del; 11 mod

8341881: [REDO] java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3

Reviewed-by: liach, sgehwolf, ihse, bpb

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

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

From bpb at openjdk.org  Mon Oct 14 17:42:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 17:42:45 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch dir
Message-ID: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>

Change property `test.src` to `test.dir`.

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

Commit messages:
 - 8341997: Tests create files in src tree instead of scratch dir

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

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

From erikj at openjdk.org  Mon Oct 14 17:54:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 17:54:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <TkWFxqqLjnbuuhBp4l7zJ14IMcLNbucK8c2fTypoJjM=.cd6d207d-4d17-4a0a-823e-f967e90b9b6d@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

I can't find any reference to `test.dir` in the jtreg documentation. I would expect to see it here https://openjdk.org/jtreg/tag-spec.html#testvars. My understanding is that you should just use the current working directory for temporary files: https://openjdk.org/jtreg/faq.html#scratch-directory

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

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2367294246

From bpb at openjdk.org  Mon Oct 14 17:58:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 17:58:12 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

The property `test.dir` has been used as a convention but I've no problem with changing it to the CWD.

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2411903557

From bpb at openjdk.org  Mon Oct 14 18:02:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 18:02:44 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>

> Change property `test.src` to `test.dir`.

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

  8341997: Replace test.dir property with CWD

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21503/files
  - new: https://git.openjdk.org/jdk/pull/21503/files/2216404d..0f2af647

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

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

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

From erikj at openjdk.org  Mon Oct 14 23:06:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:06:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <vJK4YjVEux-8jGSawkp70qZcJ61r_17mQinikCeGLMY=.1b203fba-9c87-4eda-81cc-a970b7c1e745@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2367784645

From erikj at openjdk.org  Mon Oct 14 23:06:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:06:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>
Message-ID: <Wo0A9eGSZZgQXe_JoLpOyIPNHYN5D6c1AkCXDlzdqJY=.7dde1e68-2ce0-4aaa-8ea6-084d5d85bee8@github.com>

On Mon, 14 Oct 2024 17:55:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The property `test.dir` has been used as a convention but I've no problem with changing it to the CWD.

I wasn't aware, but if it's convention, I'm ok with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412484744

From erikj at openjdk.org  Mon Oct 14 23:10:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:10:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

I'm taking this fix for a spin over night in the environment where I noticed the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412488255

From bpb at openjdk.org  Mon Oct 14 23:29:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 23:29:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
Message-ID: <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>

On Mon, 14 Oct 2024 23:07:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm taking this fix for a spin over night in the environment where I noticed the problem.

I'll hold off integrating until that is over.

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412512411

From bpb at openjdk.org  Mon Oct 14 23:34:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 23:34:22 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
Message-ID: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>

Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

Commit messages:
 - 8233451: (fs) Files.newInputStream() cannot be used with character special files

Changes: https://git.openjdk.org/jdk/pull/21508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233451
  Stats: 204 lines in 11 files changed: 188 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

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

From alanb at openjdk.org  Tue Oct 15 05:18:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 05:18:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

src/java.base/windows/native/libjava/io_util_md.h line 44:

> 42: WCHAR* currentDir(int di);
> 43: int currentDirLength(const WCHAR* path, int pathlen);
> 44: JNIEXPORT int handleAvailable(FD fd, jlong *pbytes);

This should not be exported.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:

> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
> 401:     jlong available;
> 402:     if (handleAvailable((jlong)handle, &available)) {

Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1800469509
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1800469147

From alanb at openjdk.org  Tue Oct 15 05:42:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 05:42:09 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <sgK6A1OW4YhCFAYE-gGeASpWuwFVgRPIK0yHV4ofs4Q=.19bdb957-d434-4d58-b31d-e519ee3ed07e@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Overall the approach is good, except for the Windows implementation of "available" that will need re-work. For ChannelInputStream.isOther then it's effective a stable field, we can do some improvements there.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2412941018

From jpai at openjdk.org  Tue Oct 15 07:14:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Oct 2024 07:14:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <toz-ptgJs8JkEeTm7MGh5o_Zw4GozAg9_mHwGQdjjNE=.386941b9-894d-4179-be5a-3be4acdaf69d@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

This test-only change looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2368367164

From syan at openjdk.org  Tue Oct 15 11:42:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 15 Oct 2024 11:42:20 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
Message-ID: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>

Hi all,
The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.

Additional testing:

- [ ] compile `libCreationTimeHelper.c` on Alpine docker container
- [ ] compile `libCreationTimeHelper.c` on centos6 docker container
- [ ] build jdk with release/fastdebug configure on linux x86_64
- [ ] build jdk with release/fastdebug configure on linux aarch64

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

Commit messages:
 - 8342145: File libCreationTimeHelper.c compile fails on Alpine

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

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

From mullan at openjdk.org  Tue Oct 15 13:03:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
Message-ID: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>

This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.

NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.

The code changes can be broken down into roughly the following categories:

1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.

There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 

Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most familiar with.

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

Commit messages:
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - fix setOpenURIHandler docs
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Fix whitespace
 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove windows-specific policy file as it is no longer needed.
 - clientlibs: Updated Problemlist JBS ID for javax/swing/JPopupMenu/6694823/bug6694823.java
 - Merge
 - ... and 73 more: https://git.openjdk.org/jdk/compare/a601cd2e...d05122fb

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338411
  Stats: 63777 lines in 1825 files changed: 935 ins; 59236 del; 3606 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From liach at openjdk.org  Tue Oct 15 13:03:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

@seanjmullan I think you can use many lines of command in one github comment, like

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563

From erikj at openjdk.org  Tue Oct 15 13:08:13 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 13:08:13 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
 <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
Message-ID: <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>

On Mon, 14 Oct 2024 23:26:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I'm taking this fix for a spin over night in the environment where I noticed the problem.
> 
> I'll hold off integrating until that is over.

Test successful, thanks for fixing this!

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2413865347

From acobbs at openjdk.org  Tue Oct 15 15:06:10 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 15 Oct 2024 15:06:10 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Albeit with my very basic understanding of these internals, it seems wrong that the `FileChannel` created to represent a special ends up also being a `SeekableFileChannel`. This seems like the true root of the problem - that is, the fact that these files are being labeled as seekable but they're not actually seekable is what leads to the bug.

The approach also this leads to the requirement for "fixups" like these, which are brittle and kindof a red flag that something is not quite right:

if (!(ch instanceof SeekableByteChannel sbc) ||
     (ch instanceof FileChannelImpl fci && isOther()))


In other words, we already have an interface for representing exactly this situation, so why not use it? What is the rationale for not doing so? I'm not saying there isn't one, just seeking to better understand the trade-offs...

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414194787

From dfuchs at openjdk.org  Tue Oct 15 15:19:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Impressive work. I had a look at everything source in `net`, `logging`, `jmx` and `httpclient`.

Mostly good, but I was surprised to see an explicit new `throw new SecurityException()` in `java.util.logging`; Also JMX still supports authentication and coarse authorisation, which means that `SecurityException` can still be thrown by the `JMXAuthenticator` / `MBeanServerAccessController` on the server side and thrown on the client side. I have made some suggestions.

src/java.base/share/classes/java/net/URLClassLoader.java line 667:

> 665:      * @param codesource the codesource
> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
> 667:      * @return the permissions for the codesource

Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:

> 2428:     @Deprecated(since="17", forRemoval=true)
> 2429:     public void checkAccess() {
> 2430:         throw new SecurityException();

Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:

> 157:      * is specified for the MBean.
> 158:      * @throws SecurityException if the client does not have permission
> 159:      * to perform this operation.

Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.

So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.

An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:

> 65:      *
> 66:      * @exception SecurityException if the server cannot authenticate the user
> 67:      * with the provided credentials.

Should this be reverted? Authentication has not been removed.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:

> 223:      *
> 224:      * @exception SecurityException if the connection cannot be made
> 225:      * for security reasons.

I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369425602
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801215698
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801291195
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801341618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801357691
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801362306

From alanb at openjdk.org  Tue Oct 15 15:21:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:21:11 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
Message-ID: <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>

On Tue, 15 Oct 2024 15:03:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Albeit with my very basic understanding of these internals, it seems wrong that the `FileChannel` created to represent a special ends up also being a `SeekableFileChannel`. This seems like the true root of the problem - that is, the fact that these files are being labeled as seekable but they're not actually seekable is what leads to the bug.

FileChannel implements SeekableByteChannel. You'll see exactly the same thing if you use FileChannel.open to open a special file.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414238334

From acobbs at openjdk.org  Tue Oct 15 15:21:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 15 Oct 2024 15:21:11 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
 <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>
Message-ID: <FG-s0FN_V_lzEGjPOAgXZY2s6ESFLr9JU6TCPaEizNQ=.996f34d2-fad8-473f-bcb5-8ec93e4e6e88@github.com>

On Tue, 15 Oct 2024 15:13:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> FileChannel implements SeekableByteChannel. You'll see exactly the same thing if you use FileChannel.open to open a special file.

Ah... thanks. Also (for example) `FileInputStream.getChannel()` returns a `FileChannel`, so we're stuck with it.

OK so this is an "original sin" situation which we can't fix here. Thanks for the clarification.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414264717

From bpb at openjdk.org  Tue Oct 15 15:21:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 15:21:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
Message-ID: <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>

On Tue, 15 Oct 2024 05:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> src/java.base/windows/native/libjava/io_util_md.h line 44:
> 
>> 42: WCHAR* currentDir(int di);
>> 43: int currentDirLength(const WCHAR* path, int pathlen);
>> 44: JNIEXPORT int handleAvailable(FD fd, jlong *pbytes);
> 
> This should not be exported.

Okay.

> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:
> 
>> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
>> 401:     jlong available;
>> 402:     if (handleAvailable((jlong)handle, &available)) {
> 
> Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.

Yeah, I was not sure about that. I had a standalone version before this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801398538
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801397285

From alanb at openjdk.org  Tue Oct 15 15:21:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:21:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
 <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>
Message-ID: <STP7eY1VWq8BJPtXinHdC-0UOll-IcFMOvwSdne1kzU=.fcc7bade-6af1-42cc-9b8d-9a94731b0056@github.com>

On Tue, 15 Oct 2024 15:15:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:
>> 
>>> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
>>> 401:     jlong available;
>>> 402:     if (handleAvailable((jlong)handle, &available)) {
>> 
>> Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.
>
> Yeah, I was not sure about that. I had a standalone version before this.

When/if we get to the point that FIS/FOS/RAF is implemented on FileChannel then it will become clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801401151

From alanb at openjdk.org  Tue Oct 15 15:24:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:24:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>

On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
> 
>> 2428:     @Deprecated(since="17", forRemoval=true)
>> 2429:     public void checkAccess() {
>> 2430:         throw new SecurityException();
> 
> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801415455

From dfuchs at openjdk.org  Tue Oct 15 15:36:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:36:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
Message-ID: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>

On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>> 
>>> 2428:     @Deprecated(since="17", forRemoval=true)
>>> 2429:     public void checkAccess() {
>>> 2430:         throw new SecurityException();
>> 
>> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?
>
> This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801445724

From ihse at openjdk.org  Tue Oct 15 15:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 15:42:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <V_CgYKM3b79sS7MTegDSIISOX92kZVccIePJlJ4hFzk=.b9cabb49-8f94-4d8b-80a5-c8cd66a2821d@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369826643

From duke at openjdk.org  Tue Oct 15 15:55:17 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 15:55:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
Message-ID: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>

On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a bit of forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.
>
> OK

While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:


if (System.getSecurityManager() != null) {
    foo.checkAccess();
}


I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.

But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801484176

From mullan at openjdk.org  Tue Oct 15 16:17:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 16:17:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
Message-ID: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>

On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OK
>
> While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:
> 
> 
> if (System.getSecurityManager() != null) {
>     foo.checkAccess();
> }
> 
> 
> I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.
> 
> But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801518838

From sgehwolf at openjdk.org  Tue Oct 15 16:37:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:37:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:


        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
        ...
        }


Intentional?

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369966554

From duke at openjdk.org  Tue Oct 15 16:37:22 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 16:37:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
Message-ID: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>

On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.

These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).

Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801549133

From dfuchs at openjdk.org  Tue Oct 15 16:44:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 16:44:16 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <00frHPVuBzy1HhWEnmBtfSS4CeXN3uOVVilYbvntplY=.40626317-3ede-4a7f-b906-a8fa7829a418@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

@jerboaa  Yes - this is intentional:
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414512674

From sgehwolf at openjdk.org  Tue Oct 15 16:57:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <kht8vPv-muz8n2rWPcwE6tr_AIfxSHjqRdW85e7qxQA=.3f1ea0f1-51d8-4b31-ace9-74e00b0f0152@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

> @jerboaa Yes - this is intentional:
> 
> > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414541204

From mullan at openjdk.org  Tue Oct 15 17:04:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 17:04:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
Message-ID: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>

On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>
>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
> 
> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
> 
> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
> 
> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801595566

From bpb at openjdk.org  Tue Oct 15 17:47:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 17:47:23 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
 <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
 <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>
Message-ID: <fS7qv7c2m-WS46UF8d2REiPRttIalWGn2tsPC8NHfwE=.bedf9e92-6839-43bd-8f9a-01e300f7e9e4@github.com>

On Tue, 15 Oct 2024 13:06:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Test successful, thanks for fixing this!

Thanks @erikj79 and @jaikiran for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2414642523

From bpb at openjdk.org  Tue Oct 15 17:47:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 17:47:24 GMT
Subject: Integrated: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <Yl1H5tkHQpGLrppjCYIU-vJFFznCRXjYJiM7rNpPCAs=.18de92fc-e27a-4ef2-bc6a-eb2f45c9bfd9@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

This pull request has now been integrated.

Changeset: b9cabbec
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9cabbecdac27ae8b93df88660a4a0f3f60e6828
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8341997: Tests create files in src tree instead of scratch dir

Reviewed-by: erikj, jpai

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

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

From erikj at openjdk.org  Tue Oct 15 17:52:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8aC3jj6-F-URh3DOk-64i-0FSHKwpUX7gPAvP70FUnI=.b8b29107-9a65-403f-8292-1613a401a3d3@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370152926

From cjplummer at openjdk.org  Tue Oct 15 17:52:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kAgds4PDaZp8jva1ib1vtT7Tcj2kOOf3SbiOkHnYIZE=.2c46f0ff-0a3d-43a7-900e-482ab38f03ce@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

jdk.jdi and jdk.attach changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370157272

From coleenp at openjdk.org  Tue Oct 15 18:51:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Oct 2024 18:51:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <fedkR8waMXM0YzqN0-EynQLWQ03lqgpylDzmPbAXOP0=.a774e759-073e-4e77-85de-49c69acf4904@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

HotSpot changes look great.  Will clean out the rest in [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370289526

From naoto at openjdk.org  Tue Oct 15 18:51:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Oct 2024 18:51:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <4WtQzf1WGGjNSzOuxPNvYOub8uuVyYhaad13b4RfMDI=.d7e704b1-68af-4ddd-b221-77b76c179f98@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

This is a great work! I looked through the following areas that relate to i18n/charset/console/javatime, and they all look good to me.

src/java.base/share/classes/java/util/Locale.java
src/java.base/share/classes/java/util/ResourceBundle.java
src/java.base/share/classes/java/util/TimeZone.java
src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java

test/jdk/java/io/Console/
test/jdk/java/nio/charset/spi/
test/jdk/java/time/nontestng/java/time/chrono/
test/jdk/java/util/PluggableLocale/
test/jdk/java/util/ResourceBundle/
test/jdk/java/util/TimeZone/
test/jdk/java/util/spi/ResourceBundleControlProvider/
test/jdk/sun/nio/cs/
test/jdk/sun/util/locale/provider/

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370292817

From aturbanov at openjdk.org  Tue Oct 15 19:16:13 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Oct 2024 19:16:13 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <4ZuupXOgZBT9kSv6STF4Rw_xBf4SmmsyOCeT4MtP7DY=.388a6220-573f-457a-a6df-82c3e5198b11@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
 <4ZuupXOgZBT9kSv6STF4Rw_xBf4SmmsyOCeT4MtP7DY=.388a6220-573f-457a-a6df-82c3e5198b11@github.com>
Message-ID: <tSM6_iZOkca1o10iAdQkfISjwUzfINQnnUnhfxDX--E=.a348531a-2590-43ca-9a26-704e19b356cb@github.com>

On Mon, 14 Oct 2024 10:03:55 GMT, Varada M <varadam at openjdk.org> wrote:

>> Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)
>> 
>> Ran the test for 50 times and didn't observed any timeout error.
>> Tier 1 testing successful with fastdebug VM
>> 
>> JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)
>
> Varada M has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8211851: (ch) java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out (aix)

src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 56:

> 54:     private final int pollset;
> 55: 
> 56:     private static final int ENOENT     = 2;

Suggestion:

    private static final int ENOENT = 2;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21487#discussion_r1801783925

From mchung at openjdk.org  Tue Oct 15 19:36:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Oct 2024 19:36:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Source changes in `java.base/java/lang/**`, `java.management`, and `jdk.management` module look good.  Also hotspot change.

src/java.base/share/classes/java/lang/SecurityManager.java line 72:

> 70:     private static class StackWalkerHolder {
> 71:         static final StackWalker STACK_WALKER =
> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

Suggestion:

            StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));


Method info is not needed.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370337536
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801781277

From simonis at openjdk.org  Tue Oct 15 20:32:14 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Oct 2024 20:32:14 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate [v2]
In-Reply-To: <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
 <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>
Message-ID: <ChRHcQ27OPqb07AP3_cwOgN9j78YQMZD-_jTbE8IjTs=.e0cfc119-47f6-40cc-b517-9ee81c0cf3ed@github.com>

On Fri, 11 Oct 2024 15:16:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
>> 
>> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
>> 
>> 
>> // Override fill() method to provide an extra "dummy" byte
>> // at the end of the input stream. This is required when
>> // using the "nowrap" Inflater option.
>> protected void fill() throws IOException {
>> 
>> However, zlib has not required such an extra dummy byte since 2003. 
>> 
>> 
>> Changes in 1.2.0 (9 March 2003)
>> - New and improved inflate code
>>     - Raw inflate no longer needs an extra dummy byte at end
>> ``` 
>> 
>> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
>> 
>> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
>> 
>> Testing: ZIP and ZIPFS tests run green locally. GHA also green. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Inflater and Deflater constructors taking 'nowrap' options to explain more clearly what this option does

>From the zlib-based libraries I've used ([zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib), [zlib-cloudflare](https://github.com/cloudflare/zlib.git), [zlib-jkukunas](https://github.com/jtkukunas/zlib), and [zlib-ng](https://github.com/zlib-ng/zlib-ng.git)), none of them is based on a version earlier than 1.2.0 of [zlib-madler](https://github.com/madler/zlib.git). [zlib-cloudflare](https://github.com/cloudflare/zlib.git) is based on 1.2.8 and [zlib-ng](https://github.com/zlib-ng/zlib-ng.git) was forked from the original zlib 1.2.11, all others are based (or have integrated) at least 1.2.12

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

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2414951312

From prr at openjdk.org  Tue Oct 15 21:39:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Oct 2024 21:39:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

I have looked at the source code changes in java.desktop
They are mostly OK.
I have noted text that was removed in two places in java.awt.Robot where the removal should be reverted.
I have also "grepped" the sandbox repo to identify any errors of omission - pertaining to the SE API specification, not internals - and found none.

I also noted a couple of Permission classes we should deprecate - and filed bugs on them.

I have not yet examined any of the test updates. That looks like a big job.

src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:

> 37:  * @apiNote
> 38:  * This permission cannot be used for controlling access to resources anymore
> 39:  * as the Security Manager is no longer supported.

After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

src/java.desktop/share/classes/java/awt/Robot.java line 433:

> 431:      * then a {@code SecurityException} may be thrown,
> 432:      * or the content of the returned {@code Color} is undefined.
> 433:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/java/awt/Robot.java line 460:

> 458:      * then a {@code SecurityException} may be thrown,
> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
> 460:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java line 36:

> 34:  * actions list; you either have the named permission or you don't.
> 35:  * <p>
> 36:  * The target name is the name of the audio permission.

AudioPermission is another class we should deprecate

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370309133
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801765010
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031119
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031524
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802042388

From mullan at openjdk.org  Tue Oct 15 22:12:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:12:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>

On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
> 
>> 665:      * @param codesource the codesource
>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>> 667:      * @return the permissions for the codesource
> 
> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802073264

From mullan at openjdk.org  Tue Oct 15 22:19:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
Message-ID: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>

On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
> 
>> 70:     private static class StackWalkerHolder {
>> 71:         static final StackWalker STACK_WALKER =
>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 
> Suggestion:
> 
>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
> 
> 
> Method info is not needed.

Thanks, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077370

From mullan at openjdk.org  Tue Oct 15 22:19:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>

On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/Robot.java line 433:
> 
>> 431:      * then a {@code SecurityException} may be thrown,
>> 432:      * or the content of the returned {@code Color} is undefined.
>> 433:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

> src/java.desktop/share/classes/java/awt/Robot.java line 460:
> 
>> 458:      * then a {@code SecurityException} may be thrown,
>> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
>> 460:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077916
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802078111

From mullan at openjdk.org  Tue Oct 15 22:19:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>

On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
> 
>> 223:      *
>> 224:      * @exception SecurityException if the connection cannot be made
>> 225:      * for security reasons.
> 
> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802076052

From bpb at openjdk.org  Tue Oct 15 22:37:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 22:37:26 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

 - 8233451: Remove use of handleAvailable() (Windows)
 - 8233451: Remove use of handleAvailable() (UNIX)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/235182fb..51df5d81

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

  Stats: 53 lines in 5 files changed: 41 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

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

From bpb at openjdk.org  Tue Oct 15 22:39:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 22:39:13 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
Message-ID: <Jq801AbcV2jKG0gTvmAUEmLpDWwPDzLGJW4SpnrPIfU=.8023329b-fe7b-4876-9214-43b1ebc66324@github.com>

On Tue, 15 Oct 2024 11:37:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.
> 
> Additional testing:
> 
> - [x] compile `libCreationTimeHelper.c` on Alpine docker container
> - [x] compile `libCreationTimeHelper.c` on centos6 docker container
> - [x] build jdk with release/fastdebug configure on linux x86_64
> - [x] build jdk with release/fastdebug configure on linux aarch64

This does not break any of the platforms in our test pipeline.

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

PR Comment: https://git.openjdk.org/jdk/pull/21522#issuecomment-2415287919

From syan at openjdk.org  Wed Oct 16 01:18:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Oct 2024 01:18:18 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <Jq801AbcV2jKG0gTvmAUEmLpDWwPDzLGJW4SpnrPIfU=.8023329b-fe7b-4876-9214-43b1ebc66324@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
 <Jq801AbcV2jKG0gTvmAUEmLpDWwPDzLGJW4SpnrPIfU=.8023329b-fe7b-4876-9214-43b1ebc66324@github.com>
Message-ID: <m1MQs6gnJqZHD41KtoUqDPMrOSQEed42a9oMtYv5go0=.237a41dd-5f17-4b9e-bd89-60e8e65c60ed@github.com>

On Tue, 15 Oct 2024 22:36:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> This does not break any of the platforms in our test pipeline.

Thanks for the verify.

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

PR Comment: https://git.openjdk.org/jdk/pull/21522#issuecomment-2415497265

From tprinzing at openjdk.org  Wed Oct 16 01:24:53 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 16 Oct 2024 01:24:53 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
Message-ID: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>

Adds a JFR event for socket connect operations.

Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

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

Commit messages:
 - fix default settings
 - fix merge
 - Merge branch 'master' into JDK-8310996
 - added tests and support for sockets.
 - 8310996: Add JFR event for connect operations

Changes: https://git.openjdk.org/jdk/pull/21528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310996
  Stats: 247 lines in 12 files changed: 236 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From alanb at openjdk.org  Wed Oct 16 06:31:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:31:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
Message-ID: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>

On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>> 
>>> 70:     private static class StackWalkerHolder {
>>> 71:         static final StackWalker STACK_WALKER =
>>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 
>> Suggestion:
>> 
>>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
>> 
>> 
>> Method info is not needed.
>
> Thanks, will fix.

SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have not in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802437558

From alanb at openjdk.org  Wed Oct 16 06:43:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:43:12 GMT
Subject: RFR: 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: <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@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.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 624:

> 622:                 SocketConnectEvent.commit(start, duration, isa.getHostString(), address.getHostAddress(), port, connected);
> 623:             }
> 624:         }

Would it be possible to update the JBS or PR description to indicate if the intent is to record an event when the connection cannot be established? I'm asking the change will only record an event when a connection is successfully established ("connected" is always true here).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1802451480

From alanb at openjdk.org  Wed Oct 16 06:49:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:49:16 GMT
Subject: RFR: 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: <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@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.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1006:

> 1004:         boolean connected = implConnect(sa);
> 1005:         SocketConnectEvent.offer(start, connected, sa);
> 1006:         return connected;

It would be useful if the JBS or PR could say what the intent it for SocketChannels that are configured non-blocking. I assume that implConnect will execute in <20ms (the threshold in the JFR config) so no event will be ever be recorded when configured non-blocking. It would be possible to save the timestamp when connecting, and then use in finishConnect but that does depend on timely usage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1802458279

From alanb at openjdk.org  Wed Oct 16 07:01:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 07:01:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
Message-ID: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>

On Tue, 15 Oct 2024 22:16:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 433:
>> 
>>> 431:      * then a {@code SecurityException} may be thrown,
>>> 432:      * or the content of the returned {@code Color} is undefined.
>>> 433:      * </p>
>> 
>> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.
>
> Ok, I will revert it.

The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802471843

From alanb at openjdk.org  Wed Oct 16 08:37:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:37:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <eDT17ezlw65yxabhUuwqn337hsf_yb9aZyjc7Cs2TTw=.60e28c95-d6e4-4d23-a9b6-bc0b1e0cdd55@github.com>

On Tue, 15 Oct 2024 18:57:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:
> 
>> 37:  * @apiNote
>> 38:  * This permission cannot be used for controlling access to resources anymore
>> 39:  * as the Security Manager is no longer supported.
> 
> After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

JEP 486 lists deprecating the permission classes as future work. It would be very disruptive to do this now, but will be a lot easier once the JEP is integrated and the post-JEP tasks to remove the hundreds of usages in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802617206

From mbaesken at openjdk.org  Wed Oct 16 11:38:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 11:38:10 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
Message-ID: <go2X2QEUqRq2gUu2HWtYbNv9a4WAeIr9kFpzxmpy4n0=.20b5c0c8-d45b-4074-a143-5879e2da26ce@github.com>

On Tue, 15 Oct 2024 11:37:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.
> 
> Additional testing:
> 
> - [x] compile `libCreationTimeHelper.c` on Alpine docker container
> - [x] compile `libCreationTimeHelper.c` on centos6 docker container
> - [x] build jdk with release/fastdebug configure on linux x86_64
> - [x] build jdk with release/fastdebug configure on linux aarch64

Fixes the Alpine build in our environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/21522#issuecomment-2416551800

From syan at openjdk.org  Wed Oct 16 11:48:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Oct 2024 11:48:11 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <go2X2QEUqRq2gUu2HWtYbNv9a4WAeIr9kFpzxmpy4n0=.20b5c0c8-d45b-4074-a143-5879e2da26ce@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
 <go2X2QEUqRq2gUu2HWtYbNv9a4WAeIr9kFpzxmpy4n0=.20b5c0c8-d45b-4074-a143-5879e2da26ce@github.com>
Message-ID: <2SpZTDsv4EIb6Lx4wrVsBFjpTBfOD7p-0n8sBfR6z2E=.2895aa68-8194-499a-97f4-26345f5a5f98@github.com>

On Wed, 16 Oct 2024 11:36:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Fixes the Alpine build in our environment.

Thanks for the verify.

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

PR Comment: https://git.openjdk.org/jdk/pull/21522#issuecomment-2416578096

From mullan at openjdk.org  Wed Oct 16 12:24:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 12:24:12 GMT
Subject: RFR: 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: <Ja98-AUnNpEHz68-j-pJqQCG2VXkgwShF-UPI6apN4w=.56399d6b-8bed-4fdb-9fc7-e5a5ea707b1f@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.

I think this change should have a release note.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2416674860

From weijun at openjdk.org  Wed Oct 16 13:32:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Oct 2024 13:32:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

`java.security.jgss`, `jdk.security.auth`, and `jdk.security.jgss` look mostly fine except for [one question](https://github.com/openjdk/jdk/pull/21498#pullrequestreview-2372476763).

src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:

> 29: 
> 30: /**
> 31:  * This class is for GSS security context permissions.

Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2372479736
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803106645

From duke at openjdk.org  Wed Oct 16 15:34:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Oct 2024 15:34:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
Message-ID: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>

On Wed, 16 Oct 2024 06:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks, will fix.
>
> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

**SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.

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

See?also:
- https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803352590

From mbaesken at openjdk.org  Wed Oct 16 15:42:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 15:42:12 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
Message-ID: <NACZQ7XdcKa57b_o9J0NGxXWCmtaC4gEAOq04erKtqY=.50e749d9-d455-478f-b27c-260111956044@github.com>

On Tue, 15 Oct 2024 11:37:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.
> 
> Additional testing:
> 
> - [x] compile `libCreationTimeHelper.c` on Alpine docker container
> - [x] compile `libCreationTimeHelper.c` on centos6 docker container
> - [x] build jdk with release/fastdebug configure on linux x86_64
> - [x] build jdk with release/fastdebug configure on linux aarch64

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21522#pullrequestreview-2372906339

From alanb at openjdk.org  Wed Oct 16 15:56:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 15:56:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
Message-ID: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>

On Wed, 16 Oct 2024 15:31:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.
>
> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
> 
> --------------------------------------------------------------------------------
> 
> See?also:
> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803388208

From syan at openjdk.org  Wed Oct 16 16:30:14 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Oct 2024 16:30:14 GMT
Subject: RFR: 8342145: File libCreationTimeHelper.c compile fails on Alpine
In-Reply-To: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
Message-ID: <UZCddSeY_BtK4Sh27D0T7SmL4w0PTWXJ_WD0ObAjqzI=.a4895bc1-5282-4e15-b51e-34e51d5a0cf6@github.com>

On Tue, 15 Oct 2024 11:37:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.
> 
> Additional testing:
> 
> - [x] compile `libCreationTimeHelper.c` on Alpine docker container
> - [x] compile `libCreationTimeHelper.c` on centos6 docker container
> - [x] build jdk with release/fastdebug configure on linux x86_64
> - [x] build jdk with release/fastdebug configure on linux aarch64

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21522#issuecomment-2417327725

From syan at openjdk.org  Wed Oct 16 16:30:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Oct 2024 16:30:15 GMT
Subject: Integrated: 8342145: File libCreationTimeHelper.c compile fails on
 Alpine
In-Reply-To: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
References: <4Z-rx8Fh1g_Q14STUxxkzODTSSlQt8E0lJMoFNUd1Fc=.e6a080ee-94e2-48aa-8105-d9bb9ddaf695@github.com>
Message-ID: <g8RN1Y-fjJceBVxBsn6eXV6SMLMWYlhWSXp9PTBaTbo=.b20bec1e-8e2e-49bc-bbef-682be29c7321@github.com>

On Tue, 15 Oct 2024 11:37:19 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The file `test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c` compile fail on Alpine. Alpine use musl as runtime libary, and musl doesn't provide header file `<bits/types.h>`. This PR delete `#include <bits/types.h>`, and add some typedef to fix Alpine compile failure.
> 
> Additional testing:
> 
> - [x] compile `libCreationTimeHelper.c` on Alpine docker container
> - [x] compile `libCreationTimeHelper.c` on centos6 docker container
> - [x] build jdk with release/fastdebug configure on linux x86_64
> - [x] build jdk with release/fastdebug configure on linux aarch64

This pull request has now been integrated.

Changeset: 44151f47
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44151f475fca3cf03299319b2ac9ddc533ba134d
Stats:     11 lines in 1 file changed: 8 ins; 1 del; 2 mod

8342145: File libCreationTimeHelper.c compile fails on Alpine

Reviewed-by: mbaesken

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

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

From joehw at openjdk.org  Wed Oct 16 18:03:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Oct 2024 18:03:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8MHic1Yb7xtxtU0HM8yKLAjD2pYzTWs6Z6G-Adsqcvg=.e5ea6cd4-c3bd-44cb-9b9c-c87ed2f3d0b7@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Changes in source src/java.xml, JAXP tests under test/jaxp, look good. I double-checked my notes on the test changes, they were mostly about removing the runs with Security Manager.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2373273367

From mullan at openjdk.org  Wed Oct 16 20:17:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:17:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
Message-ID: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>

On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
>> 
>> --------------------------------------------------------------------------------
>> 
>> See?also:
>> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565
>
> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803740577

From mullan at openjdk.org  Wed Oct 16 20:45:38 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:45:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
Message-ID: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>

On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803774792

From mullan at openjdk.org  Wed Oct 16 20:54:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:54:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
Message-ID: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>

On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This class is for GSS security context permissions.
> 
> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.

If there are other Permission classes you think should have their text modified or removed, let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803784698

From bpb at openjdk.org  Thu Oct 17 00:10:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 00:10:24 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on file
 junction points
Message-ID: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>

Improve support for Windows directory junctions.

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

Commit messages:
 - 8069345: (fs) FileTreeWalker throws NotDirectoryException on file junction points

Changes: https://git.openjdk.org/jdk/pull/21555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8069345
  Stats: 712 lines in 7 files changed: 690 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/21555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21555/head:pull/21555

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

From bpb at openjdk.org  Thu Oct 17 00:10:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 00:10:24 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <POxTe97-u93f3oIuLVSwSSRBrLmETzMYNP2yn737Wf4=.023817ab-d96c-4f6c-80dc-1413d832ff9f@github.com>

On Thu, 17 Oct 2024 00:05:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve support for Windows directory junctions.

A Windows directory junction is an empty (void) directory which has a reparse point with tag `IO_REPARSE_TAG_MOUNT_POINT` and a data buffer containing the name of the target of the junction, which must be an absolute path beginning with a drive letter. The  absolute path is usually expected to be to a directory, although it is possible, but perhaps non-standard, that it could be to a regular file. At present, directory junctions are in general handled transparently by Java in the same manner as symbolic links.

This request proposes to make directory junctions be seen as symbolic links by having `Files.isSymbolicLink(junction)` return `true` and to return the target of the directory junction from `Files.readSymbolicLink(junction)`. The behaviors of these two methods are the only visible changes.

Two tests are added to verify the expected behavior with junctions, one for `java.io` and the other for `java.nio.file`. Both of these tests already pass without the proposed source changes except for the sub-tests which verify the changes underlying the `Files.isSymbolicLink` and `Files.readSymbolicLink` methods on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2418188336

From bpb at openjdk.org  Thu Oct 17 01:37:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 01:37:01 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>

> Improve support for Windows directory junctions.

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

  8069345: Add os.family == windows to tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21555/files
  - new: https://git.openjdk.org/jdk/pull/21555/files/bbb8567b..7d9067f3

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

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

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

From duke at openjdk.org  Thu Oct 17 03:40:10 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 17 Oct 2024 03:40:10 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
Message-ID: <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>

On Tue, 15 Oct 2024 22:37:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Remove use of handleAvailable() (Windows)
>  - 8233451: Remove use of handleAvailable() (UNIX)

Hello.
I see that my [report](https://bugs.openjdk.org/browse/JDK-8341666) was closed as a duplicate of JDK-8233451 (the bug this PR fixes).
This does not resolve the situation with `FileInputStream`?
`java.io` will not be fixed? Practically none of the new API such as `readNBytes` could be used as it relies on calls to `lseek` on unix systems (this affects MacOS as well).
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2418429142

From alanb at openjdk.org  Thu Oct 17 05:57:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 05:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
Message-ID: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>

On Wed, 16 Oct 2024 20:14:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.
>
> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804151450

From alanb at openjdk.org  Thu Oct 17 06:12:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 06:12:20 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
Message-ID: <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>

On Thu, 17 Oct 2024 01:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve support for Windows directory junctions.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8069345: Add os.family == windows to tests

This is going to require time to think through whether this is a good idea or not. The JDK supports sym links on Windows and adding support for other unusual junctions types has the potential to introduce inconsistencies and weirdness that are outside the scope of the APIs.  I will try to get time in the next few weeks to comment but this is not a change that we should rush into.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2418598658

From varadam at openjdk.org  Thu Oct 17 07:16:56 2024
From: varadam at openjdk.org (Varada M)
Date: Thu, 17 Oct 2024 07:16:56 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v3]
In-Reply-To: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
Message-ID: <W-y2FkJiJ9ZGfzJu9RoTH-ipEJ1bPW48f50UQsiO0Gg=.76019c5f-2cfe-4d85-9b8e-f36e4c37c068@github.com>

> Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)
> 
> Ran the test for 50 times and didn't observed any timeout error.
> Tier 1 testing successful with fastdebug VM
> 
> JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)

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

  stressloopback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21487/files
  - new: https://git.openjdk.org/jdk/pull/21487/files/62f92507..b29f0986

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

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

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

From alanb at openjdk.org  Thu Oct 17 11:26:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 11:26:18 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
Message-ID: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>

On Tue, 15 Oct 2024 22:37:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Remove use of handleAvailable() (Windows)
>  - 8233451: Remove use of handleAvailable() (UNIX)

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

> 54:     private byte[] b1;
> 55: 
> 56:     private Boolean isOther = null;

I don't particularly like using a Boolean for tri-states but it's not too bad here. No need to initialize to null. It could be Stable but probably not much benefit here all usages require file I/O that dominates.

Are you going to add a comment to this field as readers might know now what "other" means? In the APIs we say "something other than a regular file, directory, or symbolic link" and maybe that could be useful here.

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

> 531:     }
> 532: 
> 533:     public int available() throws IOException {

This can be package-private. It would be useful to add a method description as FC doesn't define this method, same thing for isOther.

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

> 563:                 return isOther = nd.isOther(fd);
> 564:             } finally {
> 565:                 Blocker.end(attempted);

No need for Blocker begin/end here, we only use for direct I/O or file locking.

src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 233:

> 231: 
> 232:     return JNI_TRUE;
> 233: }

Can you check these syscalls for EINTR? Might be okay, but worth checking.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 438:

> 436: 
> 437:     BY_HANDLE_FILE_INFORMATION finfo;
> 438:     GetFileInformationByHandle(handle, &finfo);

This returns a BOOL that needs to be checked.

test/jdk/java/nio/file/Files/InputStreamTest.java line 139:

> 137:             InputStream s = Files.newInputStream(stdin);
> 138:             s.available();
> 139:         }

I assume you meant to close the input stream.

What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804577608
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804580164
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804581541
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804585370
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804586710
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804588059

From weijun at openjdk.org  Thu Oct 17 11:27:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Oct 2024 11:27:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
Message-ID: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>

On Wed, 16 Oct 2024 20:51:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
>> 
>>> 29: 
>>> 30: /**
>>> 31:  * This class is for GSS security context permissions.
>> 
>> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.
>
> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
> 
> If there are other Permission classes you think should have their text modified or removed, let me know.

All JGSS permission classes follow the same style:

In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.
 ```
In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804590136

From bpb at openjdk.org  Thu Oct 17 17:48:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 17:48:24 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
Message-ID: <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>

On Thu, 17 Oct 2024 03:37:30 GMT, xxDark <duke at openjdk.org> wrote:

> I see that my [report](https://bugs.openjdk.org/browse/JDK-8341666) was closed as a duplicate of JDK-8233451 (the bug this PR fixes). This does not resolve the situation with `FileInputStream`?` java.io` will not be fixed?

You are correct. Sorry for the confusion. Either the problem reported in [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) will be addressed in the context of this PR, or that issue will be reopened and addressed by a subsequent PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2420134433

From mullan at openjdk.org  Thu Oct 17 18:03:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Oct 2024 18:03:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
Message-ID: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>

On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
>> 
>> If there are other Permission classes you think should have their text modified or removed, let me know.
>
> All JGSS permission classes follow the same style:
> 
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.
>  ```
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.

I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1805188374

From bpb at openjdk.org  Thu Oct 17 18:05:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 18:05:40 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
 <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>
Message-ID: <M8j-Pp96fQLOB4SvSi3C3m9XAyZ03HMVsG3HqENVcPU=.7e47273e-1d2a-4ab1-a9e7-2d7225b6ccb4@github.com>

On Thu, 17 Oct 2024 17:44:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Either the problem reported in [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) will be addressed in the context of this PR, or that issue will be reopened and addressed by a subsequent PR.

@xxDark I reopened [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) which will be addressed by a separate PR. Thanks for pointing out our oversight.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2420183057

From bpb at openjdk.org  Thu Oct 17 22:14:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:14:59 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <B8Rns0_aYc_nZGjxQael8igpi7Lj5FMHGPgVSEcHStE=.40144816-89f0-4c67-affb-d2ce8477341e@github.com>

On Thu, 17 Oct 2024 11:20:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 233:
> 
>> 231: 
>> 232:     return JNI_TRUE;
>> 233: }
> 
> Can you check if any of these syscalls can fail with EINTR? I don't think so but need to check.

None of them are documented to so fail in the Linux and macOS man pages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805502975

From bpb at openjdk.org  Thu Oct 17 22:55:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:55:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v3]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

 - 8233451: Do not initialize isOther to null
 - 8233451: Address reviewer comments; convert test to JUnit 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/51df5d81..492659f6

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

  Stats: 62 lines in 4 files changed: 32 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

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

From bpb at openjdk.org  Thu Oct 17 22:55:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:55:58 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <KEfmTSY5hGpjwbKHLiY5eebwNp2u9zjK9qMzMj3I5pM=.2e29d341-401f-4707-baba-2f1a57f01de0@github.com>

On Thu, 17 Oct 2024 11:14:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 56:
> 
>> 54:     private byte[] b1;
>> 55: 
>> 56:     private Boolean isOther = null;
> 
> I don't particularly like using a Boolean for tri-states but it's not too bad here. No need to initialize to null. It could be Stable but probably not much benefit here all usages require file I/O that dominates.
> 
> Are you going to add a comment to this field as readers might know now what "other" means? In the APIs we say "something other than a regular file, directory, or symbolic link" and maybe that could be useful here.

Fixed in a163d8d and 492659f.

> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 533:
> 
>> 531:     }
>> 532: 
>> 533:     public int available() throws IOException {
> 
> This can be package-private. It would be useful to add a method description as FC doesn't define this method, same thing for isOther.

Fixed in a163d8d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805544190
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805544463

From bpb at openjdk.org  Thu Oct 17 22:59:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:59:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>

On Thu, 17 Oct 2024 11:17:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 565:
> 
>> 563:                 return isOther = nd.isOther(fd);
>> 564:             } finally {
>> 565:                 Blocker.end(attempted);
> 
> No need for Blocker begin/end here, we only use for direct I/O or file locking.

Fixed in a163d8d.

> test/jdk/java/nio/file/Files/InputStreamTest.java line 139:
> 
>> 137:             InputStream s = Files.newInputStream(stdin);
>> 138:             s.available();
>> 139:         }
> 
> I assume you meant to close the input stream.
> 
> What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.

I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
- `readAllBytes` throws before but hangs after the change;
- `readNBytes` hangs both before and after the change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805546933
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805546604

From bpb at openjdk.org  Fri Oct 18 00:00:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 00:00:04 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
Message-ID: <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>

On Thu, 17 Oct 2024 06:09:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The JDK supports sym links on Windows and adding support for other unusual junctions types has the potential to introduce inconsistencies and weirdness that are outside the scope of the APIs.

There appear to be two types of junctions for reparse points with tag `IO_REPARSE_TAG_MOUNT_POINT`: directory junctions and volume junctions. The reparse tag is set on a directory which is empty. Both of these reparse points contain a target string which represents a path.

For directory junctions, the path is an absolute path beginning with a drive letter such as

C:\Users\username\directory\subdirectory

This path is intended to be to a directory, but there is nothing preventing storing the path to a file or a symbolic link.

For volume junctions, the path uses a GUID, for example, like this

\?\Volume{blah-foo-bar-gus-blah}\


Presently, the JDK _appears_ already to support "true" directory junctions, i.e., where the target path begins with a drive letter and is an absolute path to a directory. The two new tests proposed in this request verify at least a portion of this behavior. All but two sub-tests of these tests already pass with no source changes.

> [...] this is not a change that we should rush into.

Agreed. Note that the only actual implementation changes being proposed here are

1. `Files.isSymbolicLink` would return `true` for directory junctions.
2. `Files.readSymbolicLink` would return the target of the mount point.

It is incomplete in the current form of this request, but I think tighter checks should be performed to ensure that the target does not represent a volume mount point, nor a regular file, nor a symbolic link.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2420886803

From alanb at openjdk.org  Fri Oct 18 08:09:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 08:09:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
Message-ID: <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>

On Thu, 17 Oct 2024 22:56:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 139:
>> 
>>> 137:             InputStream s = Files.newInputStream(stdin);
>>> 138:             s.available();
>>> 139:         }
>> 
>> I assume you meant to close the input stream.
>> 
>> What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.
>
> I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
> - `readAllBytes` throws before but hangs after the change;
> - `readNBytes` hangs both before and after the change.

I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1806067813

From alanb at openjdk.org  Fri Oct 18 10:47:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 10:47:08 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v3]
In-Reply-To: <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>
Message-ID: <5mXY3emfvAVuyQz3ehVNBhKDdj72MWqy8XZbddlt458=.c65db645-4e5a-4b83-9036-1bdeea8e89e0@github.com>

On Thu, 17 Oct 2024 22:55:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Do not initialize isOther to null
>  - 8233451: Address reviewer comments; convert test to JUnit 5

The latest update looks okay, maybe we might find a better special file so the readAllXXX methods can be tested.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2377752580

From alanb at openjdk.org  Fri Oct 18 11:54:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 11:54:59 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
 <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
Message-ID: <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>

On Thu, 17 Oct 2024 23:56:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Agreed. Note that the only actual implementation changes being proposed here are
> 
> 1. `Files.isSymbolicLink` would return `true` for directory junctions.
> 2. `Files.readSymbolicLink` would return the target of the mount point.
> 
> It is incomplete in the current form of this request, but I think tighter checks should be performed to ensure that the target does not represent a volume mount point, nor a regular file, nor a symbolic link.

Junctions, volume mount points, and several other reparse points are just too messy and NFTS specific to support in the standard API. Directory junctions may be semantically close but aren't quite the same thing so I fear that this will require effort to audit every I/O operation to flush out oddities. I also fear this will leading to weasel words in the specs. So not sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2422291737

From bpb at openjdk.org  Fri Oct 18 15:07:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 15:07:23 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
 <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
Message-ID: <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>

On Fri, 18 Oct 2024 08:06:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
>> - `readAllBytes` throws before but hangs after the change;
>> - `readNBytes` hangs both before and after the change.
>
> I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.

I need to investigate this. I might hold off integrating even thought it's approved until this is determined.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1806654280

From mullan at openjdk.org  Fri Oct 18 19:03:30 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:03:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
 - Sanitize the class descriptions of DelegationPermission and ServicePermission
   by removing text that refers to granting permissions, but avoid changes that
   affect the API specification, such as the description and format of input
   parameters.
 - Restored methods in RMIConnection to throw SecurityExceptions again but
   with adjusted text that avoids the word "permission".
 - Add text to class description of MBeanServer stating that implementations
   may throw SecurityException if authorization doesn't allow access to resource.
 - Restore text about needing permissions from the desktop environment in the
   getPixelColor and createScreenCapture methods.
 - Add api note to getClassContext to use StackWalker instead and
   add DROP_METHOD_INFO option to StackWalker.
 - Change checkAccess() methods to be no-ops, rather than throwing
   SecurityException.
 - Merge
 - Merge
 - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=01
  Stats: 63792 lines in 1825 files changed: 932 ins; 59211 del; 3649 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From pchilanomate at openjdk.org  Fri Oct 18 19:41:27 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads without
 Pinning
Message-ID: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>

This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.

In order to make the code review easier the changes have been split into the following initial 4 commits:

- Changes to allow unmounting a virtual thread that is currently holding monitors.
- Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
- Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
- Changes to tests, JFR pinned event, and other changes in the JDK libraries.

The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.

The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.


## Summary of changes

### Unmount virtual thread while holding monitors

As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:

- We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

- For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.

#### General notes about this part:

- Since virtual threads don't need to worry about holding monitors anymore, we don't need to count them, except for `LM_LEGACY`. So the majority of the platform dependent changes in this commit have to do with correcting this.
- Zero and x86 (32 bits) where counting monitors even though they don't implement continuations, so I fixed that to stop counting. The idea is to remove all the counting code once we remove `LM_LEGACY`.
- Macro `LOOM_MONITOR_SUPPORT` was added at the time to exclude ports that implement continuations but don't yet implement monitor support. It is removed later with the ppc commit changes.
- Since now a virtual thread can be unmounted while holding monitors, JVMTI methods `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` had to be adapted.

#### Notes specific to the tid changes:

- The tid is cached in the JavaThread object under `_lock_id`. It is set on JavaThread creation and changed on mount/unmount.
- Changes in the ObjectMonitor class in this commit are pretty much exclusively related to changing `_owner` and `_succ` from `void*` and `JavaThread*` respectively to `int64_t`.
- Although we are not trying to fix `LM_LEGACY` the tid changes apply to it as well since the inflated path is shared. Thus, in case of inflation by a contending thread, the `BasicLock*` cannot be stored in the `_owner` field as before. The `_owner` is instead set to anonymous as we do in `LM_LIGHTWEIGHT`, and the `BasicLock*` is stored in the new field `_stack_locker`.
- We already assume 32 bit platforms can handle 64 bit atomics, including `cmpxchg` ([JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776)) so the shared code can stay the same. The assembly code for the c2 fast paths has to be adapted though. On arm (32bits) we already jump directly to the slow path on inflated monitor case so there is nothing to do. For x86 (32bits), since the port is moving towards deprecation ([JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285)) there is no point in trying to optimize, so the code was changed to do the same thing we do for arm (32bits).

### Unmounting a virtual thread blocked on synchronized

Currently virtual thread unmounting is always started from Java, either because of a voluntarily call to `Thread.yield()` or because of performing some blocking operation such as I/O. Now we allow to unmount from inside the VM too, specifically when facing contention trying to acquire a Java monitor.

On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. Once the owner releases the monitor and selects it as the next successor the virtual thread will be added again to the scheduler queue to run again. The virtual thread will run and attempt to acquire the monitor again. If it succeeds then it will thaw frames as usual to continue execution back were it left off. If it fails it will unmount and wait again to be unblocked.

#### General notes about this part:

- The easiest way to review these changes is to start from the monitorenter call in the interpreter and follow all the flow of the virtual thread, from unmounting to running again.
- Currently we use a dedicated unblocker thread to submit the virtual threads back to the scheduler queue. This avoids calls to Java from monitorexit. We are experimenting on removing this limitation, but that will be left as an enhancement for a future change.
- We cannot unmount the virtual thread when the monitor enter call is coming from `jni_enter()` or `ObjectLocker` since we would need to freeze native frames.
- If freezing fails, which almost always will be due to having native frames on the stack, the virtual thread will follow the normal platform thread logic but will do a timed-park instead. This is to alleviate some deadlocks cases where the successor picked is an unmounted virtual thread that cannot run, which can happen during class loading or class initiatialization.
- After freezing all frames, and while adding itself to the `_cxq` the virtual thread could?have successfully acquired the monitor. In that case we mark the preemption as cancelled. The virtual thread will still need to go back to the preempt stub to cleanup the physical stack but instead of unmounting it will call thaw to continue execution.
- The way we jump to the preempt stub is slightly different in the compiler and interpreter. For the compiled case we just patch a return address, so no new code is added. For the interpreter we cannot do this on all platforms so we just check a flag back in the interpreter. For the latter we also need to manually restore some state after we finally acquire the monitor and resume execution. All that logic is contained in new assembler method `call_VM_preemptable()`.

#### Notes specific to JVMTI changes:
- Since we are not unmounting from Java, there is no call to `VirtualThread.yieldContinuation()`. This means that we have to execute the equivalent of `notifyJvmtiUnmount(/*hide*/true)` for unmount, and of `notifyJvmtiMount(/*hide*/false)` for mount in the VM. The former is implemented with `JvmtiUnmountBeginMark` in `Continuation::try_preempt()`. The latter is implemented in method `jvmti_mount_end()` in `ContinuationFreezeThaw` at the end of thaw.
- When unmounting from Java the vthread unmount event is posted before we try to freeze the continuation. If that fails then we post the mount event. This all happens in `VirtualThread.yieldContinuation()`. When unmounting from the VM we only post the event once we know the freeze succeeded. Since at that point we are in the middle of the VTMS transition, posting the event is done in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()` after the transition finishes. Maybe the same thing should be done when unmounting from Java.

### Unmounting a virtual thread blocked on `Object.wait()`

This commit just extends the previous mechanism to be able to unmount inside the VM on `ObjectMonitor::wait`.

####  General notes about this part:
- The mechanism works as before with the difference that now the call will come from the native wrapper. This requires to add support to the continuation code to handle native wrapper frames, which is a main part of the changes in this commit.
- Both the compiled and interpreted native wrapper code will check for preemption on return from the wait call, after we have transitioned back to `_thread_in_Java`.

####  Note specific to JVMTI changes:
- If the monitor waited event is enabled we need to post it after the wait is done but before re-acquiring the monitor. Since the virtual thread is inside the VTMS transition at that point, we cannot do that directly. Currently in the code we end the transition, post the event and start the transition again. This is not ideal, and maybe we should unmount, post the event and then run again to try reacquire the monitor.


### Test changes + JFR Updates + Library code changes

#### Tests 

- The tests in `java/lang/Thread/virtual` are updated to add more tests for monitor enter/exit and Object.wait/notify. New tests are added for JFR events, synchronized native methods, and stress testing for several scenarios.
- `test/hotspot/gtest/nmt/test_vmatree.cpp` is changed due to an alias that conflicts. 
- A small number of tests, e.g.` test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`, are updated so they are in sync with the JDK code. 
- A number of JVMTI tests are updated to fix various issues, e.g. some tests saved a JNIEnv in a static. 

#### Diagnosing remaining pinning issues

- The diagnostic option `jdk.tracePinnedThreads` is removed. 
- The JFR `jdk.VirtualThreadPinned` event is changed so that it's now recorded in the VM, and for the following cases: parking when pinned, blocking in monitor enter when pinned, Object.wait when pinned, and waiting for a class to be initialized by another thread. The changes to object monitors should mean that only a few events are recorded. Future work may change this to a sampling approach.

#### Other changes to VirtualThread class

The VirtualThread implementation includes a few robustness changes. The `park/parkNanos` methods now park on the carrier if the freeze throws OOME. Moreover, the use of transitions is reduced so that the call out to the scheduler no longer requires a temporary transition. 

#### Other changes to libraries: 

- `ReferenceQueue` is reverted to use `synchronized`, the subclass based on `ReentrantLock` is removed. This change is done now because the changes for object monitors impact this area when there is preemption polling a reference queue. 
- `java.io` is reverted to use `synchronized`. This change has been important for testing virtual threads. There will be follow-up cleanup in main-line after the JEP is integrated to remove `InternalLock` and its uses in `java.io`. 
- The epoll and kqueue based Selectors are changed to preempt when doing blocking selects. This has been useful for testing virtual threads with some libraries, e.g. JDBC drivers. We could potentially separate this update if needed but it has been included in all testing and EA builds. 
- `sun.security.ssl.X509TrustManagerImpl` is changed to eagerly initialize AnchorCertificates, a forced change due to deadlocks in this code when testing. 

## Testing 

The changes have been running in the Loom pipeline for several months now. They have also been included in EA builds throughout the year at different stages (EA builds from earlier this year did not had Object.wait() support yet but more recent ones did) so there has been some external exposure too.

The current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time.

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

Commit messages:
 - Add PPC64 support
 - Test changes + JFR Updates + Library code changes
 - Allow virtual threads to unmount when blocked on Object.wait()
 - Allow virtual threads to unmount when blocked on synchronized
 - Allow virtual threads to unmount while holding monitors

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338383
  Stats: 9459 lines in 242 files changed: 6942 ins; 1400 del; 1117 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From dholmes at openjdk.org  Fri Oct 18 19:41:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/share/runtime/javaThread.hpp line 165:

> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporal value.

Suggestion:

  // attached thread cases where this field can have a temporary value.

Presumably this is for when the attaching thread is executing the Thread constructor?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004

From pchilanomate at openjdk.org  Fri Oct 18 19:41:28 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
Message-ID: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>

On Fri, 18 Oct 2024 00:09:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/javaThread.hpp line 165:
> 
>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporal value.
> 
> Suggestion:
> 
>   // attached thread cases where this field can have a temporary value.
> 
> Presumably this is for when the attaching thread is executing the Thread constructor?

Exactly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255

From mullan at openjdk.org  Fri Oct 18 19:46:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
 <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
Message-ID: <WQXBnhvSCgaSLXJytauYL7d7V9avIZVl75sej33nL0o=.82c6cfc9-a4fd-4b44-84f1-0a268a501d04@github.com>

On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/7ea65a6febd18ad8f8fa99cfbb8687e761558594

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806946629

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
 <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
Message-ID: <uqSjjeE7SYkvbhHNrZhbu1LjbFxWuU7ZJDWMAjWf_g0=.801e961d-5085-48d8-9bff-0029b1459e94@github.com>

On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.
>
> Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

I restored the text in https://github.com/openjdk/jdk/pull/21498/commits/adf5ed789b0437fa57c87f29e6a4e6b6f7f0c92b. I've left the `@throws SecurityException` text the same, but let me know if you want that changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806948352

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
 <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
Message-ID: <YpVEi_vehntFxBVQBqfYUlJsU5xAAEphz2giQrbbHeQ=.3094111c-c59c-45b2-a13e-140c8b3d6ad3@github.com>

On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>> 
>> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
>> 
>> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
>> 
>> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.
>
> I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

I have changed `LogManager.checkAccess`, `Thread.checkAccess`, `ThreadGroup.checkAccess` to always do nothing. See the fixes in https://github.com/openjdk/jdk/pull/21498/commits/2ebb6de50194770658462507cee28b785fb30dbd and https://github.com/openjdk/jdk/pull/21498/commits/16e17b89b3dbce4f49706c032c315977dd54c315.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806950866

From mullan at openjdk.org  Fri Oct 18 19:56:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <W8LF9xitgnrJ0GXvQ2clisM9wQDS32sfJ_1w3xFvbTo=.5391529e-f6b5-40fd-a829-9803c0fdb206@github.com>

On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:
> 
>> 157:      * is specified for the MBean.
>> 158:      * @throws IOException if a general communication exception occurred.
>> 159:      * @throws UnsupportedOperationException if {@code delegationSubject} is non-null.
> 
> Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.
> 
> So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.
> 
> An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

I restored the changes to `RMIConnection` to throw `SecurityException` but adjusted the text to say "is not authorized" instead of "does not have permission". See https://github.com/openjdk/jdk/pull/21498/commits/86ff71461ef1d695c02497626facda63c496a287.

As we discussed offline, I also added a sentence to the `MBeanServer` class description to state that it and its subclasses may throw `SecurityException`s if the implementation doesn't authorize access to the underlying resource: https://github.com/openjdk/jdk/pull/21498/commits/44432e56a91a992150ee873e81282d1fe21e69ea.

> src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:
> 
>> 65:      */
>> 66:     public Subject authenticate(Object credentials);
>> 67: }
> 
> Should this be reverted? Authentication has not been removed.

Yes. See the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806952922
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953524

From mullan at openjdk.org  Fri Oct 18 19:56:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
Message-ID: <hOWAuNpI0Pigr9zYPACJJ68_-Q6uBQZuDWDD322bfg8=.ffe44b98-01a9-4125-90dc-318e48fc87b1@github.com>

On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
>> 
>>> 223:      */
>>> 224:     public static JMXConnector connect(JMXServiceURL serviceURL)
>>> 225:             throws IOException {
>> 
>> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.
>
> Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

Yes, see the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953911

From mullan at openjdk.org  Fri Oct 18 19:56:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
Message-ID: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>

On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> All JGSS permission classes follow the same style:
>> 
>> In `javax.security.auth.kerberos.DelegationPermission`:
>> 
>>  * This class is used to restrict the usage of the Kerberos
>>  * delegation model, ie: forwardable and proxiable tickets.
>>  ```
>> In `javax.security.auth.kerberos.ServicePermission`:
>> 
>>  * This class is used to protect Kerberos services and the
>>  * credentials necessary to access those services. There is a one to
>> 
>> (Updated)
>
> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806957907

From duke at openjdk.org  Fri Oct 18 20:16:43 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 18 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <V9F38E82rWG3ydtcBhl-buCMyD8G8VnLPMZtODTvpC0=.d084324c-f851-4bb6-98f5-a392e65baa24@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

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

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2378900585

From bpb at openjdk.org  Fri Oct 18 20:39:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 20:39:59 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
 <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
 <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>
Message-ID: <yQX8-l2h73amOFJcGfCJl_raktUen-AMVfFLN0gXwNs=.79ec1b15-a38a-4905-a7f6-c27bc54be466@github.com>

On Fri, 18 Oct 2024 11:51:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Directory junctions may be semantically close but aren't quite the same thing so I fear that this will require effort to audit every I/O operation to flush out oddities.

Probably. The constrained case of true directory junctions, where the mount point target is specified as an absolute path to a directory, is in effect identical to a symbolic link whose target is a directory. I don't think anything beyond this should be considered.

> I also fear this will leading to weasel words in the specs.

I am sure that some sort of verbiage would be needed, in particular to clarify the limited scope of support.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2423196177

From kevinw at openjdk.org  Fri Oct 18 20:54:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 18 Oct 2024 20:54:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <AlbXwhSqJ6KlhPzDu_C7N1p84ZxgYsYImht8GW56D4k=.0283a056-f5ee-4650-b8c9-0df0aaee1797@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for updating the wording on the JMX/management classes, looks good.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
No longer has any changes other than (C), so that should be reverted also. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423214468

From bpb at openjdk.org  Fri Oct 18 21:17:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 21:17:53 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
 <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
 <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>
Message-ID: <feE8op1MKgKXJmy2qCLervlOeELvw-TaFogz_0KMkJA=.c825f86d-c005-488e-ada2-ccb5946e7c68@github.com>

On Fri, 18 Oct 2024 15:03:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.
>
> I need to investigate this. I might hold off integrating even thought it's approved until this is determined.

> I wonder if there is another special file that could be read to EOF to allow the methods be tested.

I think that this can done using a named pipe, at least on UNIX.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1807022434

From alanb at openjdk.org  Sat Oct 19 11:56:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Oct 2024 11:56:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423661302

From tprinzing at openjdk.org  Mon Oct 21 00:37:38 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 21 Oct 2024 00:37:38 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@github.com>
Message-ID: <oYshu6aNeS70WC76sPLrLlBIfHt89ZSCW_5EUgvcksU=.573084d8-c07c-4411-8c96-61517b7d8026@github.com>

On Wed, 16 Oct 2024 06:40:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 624:
> 
>> 622:                 SocketConnectEvent.commit(start, duration, isa.getHostString(), address.getHostAddress(), port, connected);
>> 623:             }
>> 624:         }
> 
> Would it be possible to update the JBS or PR description to indicate if the intent is to record an event when the connection cannot be established? I'm asking because the change will only record an event when a connection is successfully established ("connected" is always true here).
> 
> JFR will record exceptions already of course but I think for troubleshooting purposes, recording an event when "connect" hangs and eventually fails is very useful to have.

Capturing all calls even if they threw an exception does seem pretty useful.  I'll update the JBS

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1807983535

From tprinzing at openjdk.org  Mon Oct 21 00:42:39 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 21 Oct 2024 00:42:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
Message-ID: <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>

On Wed, 16 Oct 2024 06:46:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1006:
> 
>> 1004:         boolean connected = implConnect(sa);
>> 1005:         SocketConnectEvent.offer(start, connected, sa);
>> 1006:         return connected;
> 
> It would be useful if the JBS or PR could say what the intent it for SocketChannels that are configured non-blocking. I assume that implConnect will execute in <20ms (the threshold in the JFR config) so no event will be ever be recorded when configured non-blocking. It would be possible to save the timestamp when connecting, and then use in finishConnect but that does depend on timely usage.

The non-blocking case is poorly handled.  I'll update the JBS.  The untimely use of finishConnect would cause an artificially bad looking event duration which might be a bit misleading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1807984988

From alanb at openjdk.org  Mon Oct 21 06:06:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Oct 2024 06:06:01 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
 <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>
Message-ID: <IpFVnaFTZzBwQiXA3Ba9Snur3JdksKvke3eBwlXJXQ0=.436d59c5-25db-4ceb-b83a-b2e186fd9fb7@github.com>

On Mon, 21 Oct 2024 00:39:27 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The non-blocking case is poorly handled. I'll update the JBS. The untimely use of finishConnect would cause an artificially bad looking event duration which might be a bit misleading.

My preference for now would be to focus on the blocking case. Why did my application pause for 30s? The other part to this will be the lookup methods in InetAddress as sometimes the apparent hang isn't establishing the connection but the DNS lookup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1808149416

From aturbanov at openjdk.org  Mon Oct 21 08:05:12 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Oct 2024 08:05:12 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:

> 321:             var started2 = new AtomicBoolean();
> 322: 
> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {

Suggestion:

            Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808287799

From dfuchs at openjdk.org  Mon Oct 21 13:32:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 13:32:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <RR8acwmQK7Tsg7HTc70yDPcGNetx4ATXhqTt3W0A_kA=.73aff4cf-e9f3-4846-87d8-1866a60c4c74@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for the changes in JMX and java.logging. Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382119997

From weijun at openjdk.org  Mon Oct 21 13:40:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 13:40:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
 <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
Message-ID: <-Bc_cBbnZLLWUhNTjFI_T-LLSRXSnDUS-EnV0DTQwVc=.460efd25-1595-4ff6-a262-3c1c90c7ebd0@github.com>

On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.
>
> See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

I see. I was wondering why some files are modified and some are not. The new text looks fine to me. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1808841888

From weijun at openjdk.org  Mon Oct 21 14:57:39 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 14:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ytYO_77QWIG71O6PlwBm-HJ_k6VqU2-p3Gg56o98SPI=.7e182f8b-45cb-4bd4-83ce-1e5090e3020d@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

The security-related test updates seem good to me. I noticed a few minor issues and pushed three commits (https://github.com/openjdk/jdk-sandbox/commit/807eb6e363cd78f7051ab2512fbb9fe7f72a036c, https://github.com/openjdk/jdk-sandbox/commit/b4f68e36260cba4cb9e3f72e86674666ee04f15b, and https://github.com/openjdk/jdk-sandbox/commit/02b4bf177555eaf2fa732e918448af9ff1efa8bf).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2426923546

From dfuchs at openjdk.org  Mon Oct 21 15:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 15:41:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <LgcZ50hJkMyYZe-v5naaW8WmGArxPnhYHfk6SaGqNO0=.a3d70032-1ca1-4e70-af37-40dfb2f52ddf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

For the record I have also reviewed the `java.naming` and `jdk.httpserver` source changes. They look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427040743

From pchilanomate at openjdk.org  Mon Oct 21 15:45:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:45:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Adjust spacing in test JfrEvents.java
 - Adjust comment in JavaThread.hpp
 - RISC-V: Avoid return misprediction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/6a81ccdc..8c196acd

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

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

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

From pchilanomate at openjdk.org  Mon Oct 21 15:49:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
 <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
Message-ID: <b52WbjxNH3fHsSRkdt_2lAtyr-lznkZjp4zBrh4QLGU=.9951c7b2-9dbe-433b-8e75-20ba49b57dc0@github.com>

On Fri, 18 Oct 2024 04:21:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 165:
>> 
>>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporal value.
>> 
>> Suggestion:
>> 
>>   // attached thread cases where this field can have a temporary value.
>> 
>> Presumably this is for when the attaching thread is executing the Thread constructor?
>
> Exactly.

Comment adjusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960

From pchilanomate at openjdk.org  Mon Oct 21 15:49:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
Message-ID: <wr2gUUNCp_fXQM_ggvjcOSk72PpT3vWBYDmeoL1Bsog=.6c894146-0c97-4989-8613-14ddd1153fef@github.com>

On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Adjust spacing in test JfrEvents.java
>>  - Adjust comment in JavaThread.hpp
>>  - RISC-V: Avoid return misprediction
>
> test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:
> 
>> 321:             var started2 = new AtomicBoolean();
>> 322: 
>> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {
> 
> Suggestion:
> 
>             Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809073267

From kevinw at openjdk.org  Mon Oct 21 16:12:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 21 Oct 2024 16:12:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <omJgksIX-GqCbQ_Q7xELjlDjaYtk8TlnCfXapHH1EzM=.8baa30f6-5bd9-424b-9cb7-e1e683f04e16@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewing for management, src and test changes look good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382585178

From aboldtch at openjdk.org  Mon Oct 21 16:26:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 21 Oct 2024 16:26:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
Message-ID: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>

On Mon, 21 Oct 2024 15:45:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Adjust spacing in test JfrEvents.java
>  - Adjust comment in JavaThread.hpp
>  - RISC-V: Avoid return misprediction

I've done an initial look through of the hotspot changes.

In addition to my comments, I have looked at two more things.

One is to remove the _waiters reference counter from deflation and only use the _contentions reference counter. As well as tying the _contentions reference counter to the ObjectWaiter, so that it is easier to follow its lifetime, instead of these naked add_to_contentions, now that the ObjectWaiter does not have a straight forward scope, but can be frozen, and thawed on different threads. 46dacdf96999154e808d21e80b4d4e87f73bc802

Then I looked at typing up the thread / lock ids as an enum class 34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Either of these could be future RFEs.

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:

> 229: 
> 230: StubFrame::~StubFrame() {
> 231:   __ epilogue(_use_pop_on_epilogue);

Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
e.g.
```C++
enum return_state_t {
  does_not_return, requires_return, requires_pop_epilogue_return
};

StubFrame::~StubFrame() {
  if (_return_state == does_not_return) {
    __ should_not_reach_here();
  } else {
    __ epilogue(_return_state == requires_pop_epilogue_return);
  }
}

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:

> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.

Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:

> 378:     lea(t2_owner_addr, owner_address);
> 379: 
> 380:     // CAS owner (null => current thread id).

I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 

Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:

> 298:   CodeBlob* cb = top.cb();
> 299: 
> 300:   if (cb->frame_size() == 2) {

Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:

> 311: 
> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);

Is there a reason for the mix of `2` and `frame::metadata_words`?

Maybe this could be
```C++
    intptr_t* const unadjusted_sp = sp;
    sp -= frame::metadata_words;
    sp[-2] = unadjusted_sp[-2];
    sp[-1] = unadjusted_sp[-1];

    log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
                                              " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:

> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
> 1274:   ::continuation_enter_cleanup(masm);
> 1275: }

Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

src/hotspot/cpu/x86/assembler_x86.cpp line 2866:

> 2864:     emit_int32(0);
> 2865:   }
> 2866: }

Is it possible to make this more general and explicit instead of a sequence of bytes?

Something along the lines of:
```C++
  const address tar = L.is_bound() ? target(L) : pc();
  const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);

  InstructionMark im(this);
  emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
  if (!L.is_bound()) {
    // Patch @0x8D opcode
    L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
  }
  // Register and [rip+disp] operand
  emit_modrm(0b00, raw_encode(dst), 0b101);
  // Adjust displacement by sizeof lea instruction
  int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
  assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
  emit_int32(disp);


and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

src/hotspot/share/oops/stackChunkOop.cpp line 471:

> 469:     }
> 470:   }
> 471: }

Can we turn these three very similar loops into one? In my opinion, it is easier to parse.

```C++
void stackChunkOopDesc::copy_lockstack(oop* dst) {
  const int cnt = lockstack_size();
  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
  const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
  const auto get_obj = [&](intptr_t* at) -> oop {
    if (requires_gc_barriers) {
      if (requires_uncompress) {
        return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
      }
      return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
    }
    return *reinterpret_cast<oop*>(at);
  };

  intptr_t* lockstack_start = start_address();
  for (int i = 0; i < cnt; i++) {
    oop mon_owner = get_obj(&lockstack_start[i]);
    assert(oopDesc::is_oop(mon_owner), "not an oop");
    dst[i] = mon_owner;
  }
}

src/hotspot/share/prims/jvmtiExport.cpp line 1681:

> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.

Suggestion:

  // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:

> 2536:   Method* m = hf.interpreter_frame_method();
> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;

Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

src/hotspot/share/runtime/frame.cpp line 535:

> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
> 534:   return thread_addr;
> 535: #endif

With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

src/hotspot/share/runtime/javaThread.cpp line 1545:

> 1543:     if (is_vthread_mounted()) {
> 1544:       // _lock_id is the thread ID of the mounted virtual thread
> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());

What is the interaction here with `switchToCarrierThread` and the window between?

        carrier.setCurrentThread(carrier);
        Thread.setCurrentLockId(this.threadId());

Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

src/hotspot/share/runtime/objectMonitor.hpp line 184:

> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
> 183:   //   DEFLATER_MARKER must *not* have that bit set.
> 184:   static const int64_t DEFLATER_MARKER = 2;

The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

src/hotspot/share/runtime/objectMonitor.hpp line 186:

> 184:   static const int64_t DEFLATER_MARKER = 2;
> 185: 
> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.

Suggestion:

  int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

src/hotspot/share/runtime/synchronizer.cpp line 1467:

> 1465:       markWord dmw = inf->header();
> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {

Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808181783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808189977
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808208652
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808282892
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808261926
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808318304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808358874
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808706427
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808460330
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809032469
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809065834
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809091338
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809092367
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830

From mullan at openjdk.org  Mon Oct 21 17:24:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Oct 2024 17:24:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
Message-ID: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>

On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427301539

From prr at openjdk.org  Mon Oct 21 21:24:30 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Oct 2024 21:24:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 55:

> 53:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false w.policy
> 54:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false rw.policy
> 55:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest true rwd.policy

Looks to me like we should delete these 3 policy files.
Also this test isn't about Permissions anymore. So should be renamed to CacheUsedTest 
Then we can get rid of the misspelt directory. in a follow up.Probably do this

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:

> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
> 75: 
> 76:         if (args.length > 1) {

The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?

Also the messing around with exceptions at the end of the test is pointless

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809540920
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809544420

From pchilanomate at openjdk.org  Tue Oct 22 02:14:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:

 - Fix comments in objectMonitor.hpp
 - Move frame::saved_thread_address() to platform dependent files
 - Fix typo in jvmtiExport.cpp
 - remove usage of frame::metadata_words in possibly_adjust_frame()
 - Fix comments in c2 locking paths
 - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/8c196acd..23d1a2be

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

  Stats: 253 lines in 19 files changed: 122 ins; 97 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Tue Oct 22 02:14:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>

On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:
> 
>> 229: 
>> 230: StubFrame::~StubFrame() {
>> 231:   __ epilogue(_use_pop_on_epilogue);
> 
> Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
> e.g.
> ```C++
> enum return_state_t {
>   does_not_return, requires_return, requires_pop_epilogue_return
> };
> 
> StubFrame::~StubFrame() {
>   if (_return_state == does_not_return) {
>     __ should_not_reach_here();
>   } else {
>     __ epilogue(_return_state == requires_pop_epilogue_return);
>   }
> }

Yes, that's much better. I changed it in both aarch64 and riscv.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:
> 
>> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
>> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
>> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.
> 
> Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

I removed this comment about what other values might be stored in _owner since we don't need to handle those cases here.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
> 
>> 378:     lea(t2_owner_addr, owner_address);
>> 379: 
>> 380:     // CAS owner (null => current thread id).
> 
> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
> 
> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:
> 
>> 311: 
>> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);
> 
> Is there a reason for the mix of `2` and `frame::metadata_words`?
> 
> Maybe this could be
> ```C++
>     intptr_t* const unadjusted_sp = sp;
>     sp -= frame::metadata_words;
>     sp[-2] = unadjusted_sp[-2];
>     sp[-1] = unadjusted_sp[-1];
> 
>     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>                                               " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

I removed the use of frame::metadata_words from the log statement instead to make it consistent, since we would still implicitly be assuming metadata_words it's 2 words when we do the copying. We could use a memcpy and refer to metadata_words, but I think it is clear this way since we are explicitly talking about the 2 extra words missing from the runtime frame as the comment explains.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809745804
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746249
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746397
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046

From pchilanomate at openjdk.org  Tue Oct 22 02:23:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:23:16 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>

On Mon, 21 Oct 2024 07:57:31 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
> 
>> 298:   CodeBlob* cb = top.cb();
>> 299: 
>> 300:   if (cb->frame_size() == 2) {
> 
> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

We could also check the caller of the runtime frame, something like:

#ifdef ASSERT
  RegisterMap map(JavaThread::current(),
                  RegisterMap::UpdateMap::skip,
                  RegisterMap::ProcessFrames::skip,
                  RegisterMap::WalkContinuation::skip);
  frame caller = top.sender(&map);
  assert(caller.is_compiled_frame(), "");
  assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
#endif

Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:
> 
>> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
>> 1274:   ::continuation_enter_cleanup(masm);
>> 1275: }
> 
> Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

Since we have 3 free static functions to handle the continuation entry(create, fill, cleanup) I would prefer to keep the cleanup one for consistency. We could also change them all to be members of SharedRuntime. But except for the exception I added for continuation_enter_cleanup(), all these are called by gen_continuation_enter/gen_continuation_yield() which are also static free functions.

> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
> 
>> 2864:     emit_int32(0);
>> 2865:   }
>> 2866: }
> 
> Is it possible to make this more general and explicit instead of a sequence of bytes?
> 
> Something along the lines of:
> ```C++
>   const address tar = L.is_bound() ? target(L) : pc();
>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
> 
>   InstructionMark im(this);
>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>   if (!L.is_bound()) {
>     // Patch @0x8D opcode
>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>   }
>   // Register and [rip+disp] operand
>   emit_modrm(0b00, raw_encode(dst), 0b101);
>   // Adjust displacement by sizeof lea instruction
>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>   emit_int32(disp);
> 
> 
> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

I'll test it out but looks fine.

> src/hotspot/share/prims/jvmtiExport.cpp line 1681:
> 
>> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.
> 
> Suggestion:
> 
>   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

Fixed.

> src/hotspot/share/runtime/frame.cpp line 535:
> 
>> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
>> 534:   return thread_addr;
>> 535: #endif
> 
> With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

I moved it to the platform dependent files.

> src/hotspot/share/runtime/objectMonitor.hpp line 184:
> 
>> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
>> 183:   //   DEFLATER_MARKER must *not* have that bit set.
>> 184:   static const int64_t DEFLATER_MARKER = 2;
> 
> The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

Removed the comments.

> src/hotspot/share/runtime/objectMonitor.hpp line 186:
> 
>> 184:   static const int64_t DEFLATER_MARKER = 2;
>> 185: 
>> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.
> 
> Suggestion:
> 
>   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

Fixed.

> src/hotspot/share/runtime/synchronizer.cpp line 1467:
> 
>> 1465:       markWord dmw = inf->header();
>> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
>> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {
> 
> Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

Yes, it's just a consequence of using tid as the owner, not really related to freezing. So when a thread inflates a monitor that is already owned we cannot store the BasicLock* in the _owner field anymore, since it can clash with some tid, so we mark it as anonymously owned instead. The owner will fix it here when trying to get the monitor, as we do with LM_LIGHTWEIGHT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809753868
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749481
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749657
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750552
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750685
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940

From bpb at openjdk.org  Tue Oct 22 02:40:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 02:40:44 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

  8233451: Add tests for read{All,N}Bytes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/492659f6..ead1b59b

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

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

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

From dholmes at openjdk.org  Tue Oct 22 07:44:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 07:44:22 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

First, congratulations on an exceptional piece of work @pchilano .  

Also thank you for the very clear breakdown and description in the PR as that helps immensely with trying to digest a change of this size.

The overall operational behaviour of this change seems very solid. My only concern is whether the unparker thread may become a bottleneck in some scenarios, but that is a bridge we will have to cross if we come to it.

My initial comments mainly come from just trying to understand the top-level changes around the use of the thread-id as the monitor owner. I have a number of suggestions on naming (mainly `is_x` versus `has_x`) and on documenting the API methods more clearly. None of which are showstoppers and some of which pre-exist. Unfortunately though you will need to fix the spelling of `succesor`.

Thanks

src/hotspot/share/runtime/objectMonitor.hpp line 47:

> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 47: // See next_waiter(), first_waiter(), etc.

This to-do is likely no longer relevant with the current changes.

src/hotspot/share/runtime/objectMonitor.hpp line 288:

> 286:   // Returns true if this OM has an owner, false otherwise.
> 287:   bool      has_owner() const;
> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.

null is not an int64_t value.

src/hotspot/share/runtime/objectMonitor.hpp line 292:

> 290: 
> 291:   static int64_t owner_for(JavaThread* thread);
> 292:   static int64_t owner_for_oop(oop vthread);

Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   // Simply set _owner field to new_value; current value must match old_value.
> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);

Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

src/hotspot/share/runtime/objectMonitor.hpp line 303:

> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 303:   // Simply set _owner field to current; current value must match basic_lock_p.

Comment is no longer accurate

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:   // _owner field. Returns the prior value of the _owner field.
> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);

Similar to set_owner* need better comments describing API.

src/hotspot/share/runtime/objectMonitor.hpp line 311:

> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 310: 
> 311:   bool      is_succesor(JavaThread* thread);

I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

src/hotspot/share/runtime/objectMonitor.hpp line 315:

> 313:   void      set_succesor(oop vthread);
> 314:   void      clear_succesor();
> 315:   bool      has_succesor();

Sorry but `successor` has two `s` before `or`.

src/hotspot/share/runtime/objectMonitor.hpp line 317:

> 315:   bool      has_succesor();
> 316: 
> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }

Again `has_owner` seems more appropriate

src/hotspot/share/runtime/objectMonitor.hpp line 323:

> 321:   }
> 322: 
> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

src/hotspot/share/runtime/objectMonitor.hpp line 333:

> 331:   bool is_stack_locker(JavaThread* current);
> 332:   BasicLock* stack_locker() const;
> 333:   void set_stack_locker(BasicLock* locker);

Again `is` versus `has`, plus some general comments describing the API.

src/hotspot/share/runtime/threadIdentifier.cpp line 30:

> 28: 
> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
> 30: static const int64_t INITIAL_TID = 3;

Can we express this in terms of those reserved values, or are they inaccessible?

src/java.base/share/classes/java/lang/Thread.java line 731:

> 729: 
> 730:         if (attached && VM.initLevel() < 1) {
> 731:             this.tid = 3;  // primordial thread

The comment before the `ThreadIdentifiers` class needs updating to account for this change.

src/java.base/share/classes/java/lang/VirtualThread.java line 109:

> 107:      *
> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter

Should this say something similar to the parked case, about the "yield" being successful?

src/java.base/share/classes/java/lang/VirtualThread.java line 110:

> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue

Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

src/java.base/share/classes/java/lang/VirtualThread.java line 111:

> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter

Presumably this one means it acquired the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 115:

> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
> 114:      *   WAITING -> WAITED         // waiting on monitor
> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner

Waiting to re-enter the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 178:

> 176:     // timed-wait support
> 177:     private long waitTimeout;
> 178:     private byte timedWaitNonce;

Strange name - what does this mean?

src/java.base/share/classes/java/lang/VirtualThread.java line 530:

> 528:                 && carrier == Thread.currentCarrierThread();
> 529:         carrier.setCurrentThread(carrier);
> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread

I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810027786
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810033016
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810035434
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810037658
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810036007
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810041017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810046285
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810049295
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810076019
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810111255
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113028
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810114488
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810116177
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810131339

From psadhukhan at openjdk.org  Tue Oct 22 08:11:35 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:11:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:

> 24: import javax.swing.SwingUtilities;
> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
> 26: /*

I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810185617

From psadhukhan at openjdk.org  Tue Oct 22 08:19:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:19:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:

> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
> 48:     }
> 49: 

Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810199838

From psadhukhan at openjdk.org  Tue Oct 22 09:01:38 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:01:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1EhcQfR-j3LoYCg_GkqbbJGXZEEF7PQgXtEfq_MZFZw=.6db08c42-646e-4cc1-b704-07820ae128bb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:

> 29: /**
> 30:  * @test
> 31:  * @key headful

javadoc style /** at the beginning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810285947

From psadhukhan at openjdk.org  Tue Oct 22 09:07:51 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:07:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <YNmEi00IsUjIq2jyebS_mjfWgyUlkz9lx4Hlw2PE5yc=.e917162c-9b2c-4c14-ace0-f4fe31e4cf5a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:

> 46:         test.setupUI();
> 47:         test.testApplication();
> 48:         test.testApplet();

I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810297085

From psadhukhan at openjdk.org  Tue Oct 22 09:12:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:12:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <rb-fYphAyA6BGkUU1fouWA9XPKElgZTf13MGIgbv2gc=.1d78026e-00e6-4f0e-b194-a4df08e8688e@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:

> 64:         }
> 65: 
> 66:         // Show popup as if from an applet

remove applet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810309276

From psadhukhan at openjdk.org  Tue Oct 22 09:19:31 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:19:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1rvnBCeqVl1aLtZcR0YYv7abOQlZ7WNQrOQgH359CVw=.ad43bb44-7be8-429b-aea7-ea4cd8ad507c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:

> 115:             }
> 116:             popup.setVisible(false);
> 117:             frame.dispose();

The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:

> 27:  * @test
> 28:  * @bug 6622002
> 29:  * @author Alexander Potochkin

remove @author tag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810327184
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810331078

From psadhukhan at openjdk.org  Tue Oct 22 09:32:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:32:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:

> 43:         JTable table = new JTable();
> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
> 45:         if (de == null) {

I guess we can test this without SM since it tests SwingLazyValue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810353747

From alanb at openjdk.org  Tue Oct 22 10:20:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 10:20:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
Message-ID: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>

On Tue, 22 Oct 2024 02:40:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Add tests for read{All,N}Bytes

This update looks good, just a bit minor nits. I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

test/jdk/java/nio/file/Files/InputStreamTest.java line 29:

> 27:  * @library .. /test/lib
> 28:  * @build jdk.test.lib.Platform
> 29:  * @run junit InputStreamTest

I think this will need --enable-native-access=ALL-UNNAMED.

test/jdk/java/nio/file/Files/InputStreamTest.java line 99:

> 97:                     try {
> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
> 99:                         {

The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2384729469
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1810439366
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1810441547

From michaelm at openjdk.org  Tue Oct 22 11:53:39 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Oct 2024 11:53:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

test/jdk/java/net/URLPermission/OpenURL.java line 30:

> 28:  * @run main/othervm OpenURL
> 29:  */
> 30: 

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2384948510
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810575350

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>

On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/javaThread.cpp line 1545:
> 
>> 1543:     if (is_vthread_mounted()) {
>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
> 
> What is the interaction here with `switchToCarrierThread` and the window between?
> 
>         carrier.setCurrentThread(carrier);
>         Thread.setCurrentLockId(this.threadId());
> 
> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.

In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>

On Tue, 22 Oct 2024 07:28:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
> 
>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>> 114:      *   WAITING -> WAITED         // waiting on monitor
>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
> 
> Waiting to re-enter the monitor?

yes

> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
> 
>> 176:     // timed-wait support
>> 177:     private long waitTimeout;
>> 178:     private byte timedWaitNonce;
> 
> Strange name - what does this mean?

Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267

From alanb at openjdk.org  Tue Oct 22 12:08:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:08:19 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>

On Tue, 22 Oct 2024 07:39:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
> 
>> 528:                 && carrier == Thread.currentCarrierThread();
>> 529:         carrier.setCurrentThread(carrier);
>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
> 
> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).

More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265

From dholmes at openjdk.org  Tue Oct 22 12:20:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 12:20:13 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
Message-ID: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>

On Tue, 22 Oct 2024 12:05:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
>> 
>>> 528:                 && carrier == Thread.currentCarrierThread();
>>> 529:         carrier.setCurrentThread(carrier);
>>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
>> 
>> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??
>
> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
> 
> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

Okay but ....
1. We have the current virtual thread
2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473

From alanb at openjdk.org  Tue Oct 22 12:34:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:34:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
Message-ID: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>

On Tue, 22 Oct 2024 12:17:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
>> 
>> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.
>
> Okay but ....
> 1. We have the current virtual thread
> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960

From dfuchs at openjdk.org  Tue Oct 22 13:37:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 13:37:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
Message-ID: <AOTi73-spmeUDB5J44UY2JsXYmZN9rNHl8oXlXTlgDQ=.f159726c-1867-4c4e-9a44-86bd185f763c@github.com>

On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/URLPermission/OpenURL.java line 30:
> 
>> 28:  * @run main/othervm OpenURL
>> 29:  */
>> 30: 
> 
> Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

It could - but technically openConnection / getInputStream could still throw if there was an issue with the provided URL. The difference here is that with a SecurityManager the connection would be rejected with a SecurityException before the connection was made. Without a security manager, the connection will go through, so you need the server simulation (can't rely on getting IOException assuming nobody would be listening).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810741690

From aboldtch at openjdk.org  Tue Oct 22 13:50:32 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:50:32 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <qvYgffEQcyKQk1ojTcELnXVEQHQj1VcKgP-WxTiGVIE=.a50014b9-52d2-48ac-a5c7-4c506f68db09@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:

> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
> 2246: 
> 2247:     chunk->set_lockstack_size(0);

After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.

Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.


diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
index d3d63533eed..f737bd2db71 100644
--- a/src/hotspot/share/oops/stackChunkOop.cpp
+++ b/src/hotspot/share/oops/stackChunkOop.cpp
@@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
   }
 }
 
+void stackChunkOopDesc::clear_lockstack() {
+  const int cnt = lockstack_size();
+  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
+  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
+  const auto clear_obj = [&](intptr_t* at) {
+    if (requires_uncompress) {
+      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
+    } else {
+      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
+    }
+  };
+
+  if (requires_gc_barriers) {
+    intptr_t* lockstack_start = start_address();
+    for (int i = 0; i < cnt; i++) {
+      clear_obj(&lockstack_start[i]);
+    }
+  }
+  set_lockstack_size(0);
+  set_has_lockstack(false);
+}
+
 void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
   if (*((juint*)this) == badHeapWordVal) {
     st->print_cr("BAD WORD");
diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
index 28e0576801e..928e94dd695 100644
--- a/src/hotspot/share/oops/stackChunkOop.hpp
+++ b/src/hotspot/share/oops/stackChunkOop.hpp
@@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
   void fix_thawed_frame(const frame& f, const RegisterMapT* map);
 
   void copy_lockstack(oop* start);
+  void clear_lockstack();
 
   template <typename OopT, class StackChunkLockStackClosureType>
   inline void iterate_lockstack(StackChunkLockStackClosureType* closure);
diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 5b6e48a02f3..e7d505bb9b1 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -2244,8 +2244,7 @@ NOINLINE intptr_t* Thaw<ConfigT>::thaw_slow(stackChunkOop chunk, Continuation::t
     chunk->copy_lockstack(tmp_lockstack);
     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
 
-    chunk->set_lockstack_size(0);
-    chunk->set_has_lockstack(false);
+    chunk->clear_lockstack();
     retry_fast_path = true;
   }
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911

From aboldtch at openjdk.org  Tue Oct 22 13:54:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:54:36 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:

> 2232:     retry_fast_path = true;
> 2233:   } else {
> 2234:     relativize_chunk_concurrently(chunk);

Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 

While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765

From aph at openjdk.org  Tue Oct 22 15:26:30 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:26:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

>     * We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519

From mullan at openjdk.org  Tue Oct 22 15:28:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Oct 2024 15:28:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
Message-ID: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>

On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
> 
>> 24: import javax.swing.SwingUtilities;
>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>> 26: /*
> 
> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @key headful
> 
> javadoc style /** at the beginning

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:
> 
>> 64:         }
>> 65: 
>> 66:         // Show popup as if from an applet
> 
> remove applet

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 6622002
>> 29:  * @author Alexander Potochkin
> 
> remove @author tag

Not specific to JEP 486, this should be done as part of a different issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810939227
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810942471
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943153
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943359

From aph at openjdk.org  Tue Oct 22 15:40:14 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:40:14 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:

> 58: 
> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);

Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647

From aph at openjdk.org  Tue Oct 22 15:53:21 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
Message-ID: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>

On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
> 
>> 58: 
>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
> 
> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810985771

From aph at openjdk.org  Tue Oct 22 15:53:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:

> 5339: 
> 5340: void MacroAssembler::inc_held_monitor_count() {
> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::inc_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:

> 5355: 
> 5356: void MacroAssembler::dec_held_monitor_count() {
> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::dec_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022

From aph at openjdk.org  Tue Oct 22 15:58:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:58:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
Message-ID: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>

On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>> 
>>> 58: 
>>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
>> 
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
>> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
>
> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810998545

From bpb at openjdk.org  Tue Oct 22 16:05:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 16:05:42 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
Message-ID: <CPDYC8n3_a3QGffwYvCjoSO9MdK_VJ8kw3MdezTBsV0=.cbfd98e1-f7ef-4f70-b076-d70e3231d6c3@github.com>

On Tue, 22 Oct 2024 10:15:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8233451: Add tests for read{All,N}Bytes
>
> test/jdk/java/nio/file/Files/InputStreamTest.java line 29:
> 
>> 27:  * @library .. /test/lib
>> 28:  * @build jdk.test.lib.Platform
>> 29:  * @run junit InputStreamTest
> 
> I think this will need --enable-native-access=ALL-UNNAMED.

It works as is in the CI.

> test/jdk/java/nio/file/Files/InputStreamTest.java line 99:
> 
>> 97:                     try {
>> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
>> 99:                         {
> 
> The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.

Thanks, I'll clean it up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811008472
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811009366

From bpb at openjdk.org  Tue Oct 22 16:26:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 16:26:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
Message-ID: <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>

On Tue, 22 Oct 2024 10:16:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

I already have to an extent but will run again with more platforms and repeats.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2429725100

From prr at openjdk.org  Tue Oct 22 16:53:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Oct 2024 16:53:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
Message-ID: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>

On Tue, 22 Oct 2024 15:22:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
>> 
>>> 24: import javax.swing.SwingUtilities;
>>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>>> 26: /*
>> 
>> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
>
> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

Agreed. This is not a "clean up / update tests" task.
If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

>> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
>> 
>>> 29: /**
>>> 30:  * @test
>>> 31:  * @key headful
>> 
>> javadoc style /** at the beginning
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed. No need to touch.

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
>> 
>>> 27:  * @test
>>> 28:  * @bug 6622002
>>> 29:  * @author Alexander Potochkin
>> 
>> remove @author tag
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811067982
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811068956
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811070418

From duke at openjdk.org  Tue Oct 22 18:09:06 2024
From: duke at openjdk.org (Louis Bergelson)
Date: Tue, 22 Oct 2024 18:09:06 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
Message-ID: <r662kCM8bAQA_NAvkT9KmmJeHFhrCPN2hG4cBJRGi54=.1dc5378c-7070-47a4-9c90-4e1ed7177670@github.com>

On Tue, 22 Oct 2024 02:40:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Add tests for read{All,N}Bytes

? Thanks for these changes!

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2429926276

From pchilanomate at openjdk.org  Tue Oct 22 19:01:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:01:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Make lea with RIP-relative addressing more general

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/23d1a2be..81e5c6d0

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

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

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

From pchilanomate at openjdk.org  Tue Oct 22 19:07:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
Message-ID: <LXvYQLMhjGyozdv2SaLbBGAv7rujDnS1jd9JyvUTHBw=.8a7c1706-9df3-4d17-b6e1-a230db585669@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
>> 
>>> 2864:     emit_int32(0);
>>> 2865:   }
>>> 2866: }
>> 
>> Is it possible to make this more general and explicit instead of a sequence of bytes?
>> 
>> Something along the lines of:
>> ```C++
>>   const address tar = L.is_bound() ? target(L) : pc();
>>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
>> 
>>   InstructionMark im(this);
>>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>>   if (!L.is_bound()) {
>>     // Patch @0x8D opcode
>>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>>   }
>>   // Register and [rip+disp] operand
>>   emit_modrm(0b00, raw_encode(dst), 0b101);
>>   // Adjust displacement by sizeof lea instruction
>>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>>   emit_int32(disp);
>> 
>> 
>> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.
>
> I'll test it out but looks fine.

Done. I simplified the code a bit to make it more readable. It also follows the current style of keeping the cases separate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811237106

From pchilanomate at openjdk.org  Tue Oct 22 19:07:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
Message-ID: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>

On Tue, 22 Oct 2024 13:51:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
> 
>> 2232:     retry_fast_path = true;
>> 2233:   } else {
>> 2234:     relativize_chunk_concurrently(chunk);
> 
> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
> 
> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
> 
>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>> 2246: 
>> 2247:     chunk->set_lockstack_size(0);
> 
> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
> 
> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
> 
> 
> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
> index d3d63533eed..f737bd2db71 100644
> --- a/src/hotspot/share/oops/stackChunkOop.cpp
> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>    }
>  }
>  
> +void stackChunkOopDesc::clear_lockstack() {
> +  const int cnt = lockstack_size();
> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
> +  const auto clear_obj = [&](intptr_t* at) {
> +    if (requires_uncompress) {
> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
> +    } else {
> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> +    }
> +  };
> +
> +  if (requires_gc_barriers) {
> +    intptr_t* lockstack_start = start_address();
> +    for (int i = 0; i < cnt; i++) {
> +      clear_obj(&lockstack_start[i]);
> +    }
> +  }
> +  set_lockstack_size(0);
> +  set_has_lockstack(false);
> +}
> +
>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>    if (*((juint*)this) == badHeapWordVal) {
>      st->print_cr("BAD WORD");
> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
> index 28e0576801e..928e94dd695 100644
> --- a/src/hotspot/share/oops/stackChunkOop.hpp
> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>  
>    void copy_lockstack(oop* start);
> +  void clear_lockstack();
>  
>    template <typename OopT, class StackChunkLockSta...

Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206

From pchilanomate at openjdk.org  Tue Oct 22 19:07:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
Message-ID: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>

On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1545:
>> 
>>> 1543:     if (is_vthread_mounted()) {
>>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
>> 
>> What is the interaction here with `switchToCarrierThread` and the window between?
>> 
>>         carrier.setCurrentThread(carrier);
>>         Thread.setCurrentLockId(this.threadId());
>> 
>> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).
>
> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
> 
> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811240529

From honkar at openjdk.org  Tue Oct 22 20:52:28 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:52:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <CkRcFjfurFSz7TjPgF5jqUyjfutH-vBHQvmHLYXNB7Y=.cd1bac46-fd00-4186-aca8-91476983b976@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

@prsadhuk Addressed review comments in the following jep486 branch commit: 
https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e

1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430237067

From honkar at openjdk.org  Tue Oct 22 20:58:31 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:58:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
Message-ID: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>

On Tue, 22 Oct 2024 08:16:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
> 
>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>> 48:     }
>> 49: 
> 
> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

Updated

> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:
> 
>> 46:         test.setupUI();
>> 47:         test.testApplication();
>> 48:         test.testApplet();
> 
> I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

Updated. Repurposed the test.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
> 
>> 115:             }
>> 116:             popup.setVisible(false);
>> 117:             frame.dispose();
> 
> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811381885
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382077
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382336

From honkar at openjdk.org  Tue Oct 22 21:04:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 21:04:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
Message-ID: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>

On Tue, 22 Oct 2024 09:29:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
> 
>> 43:         JTable table = new JTable();
>> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
>> 45:         if (de == null) {
> 
> I guess we can test this without SM since it tests SwingLazyValue?

I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811400040

From mchung at openjdk.org  Tue Oct 22 21:39:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 21:39:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:

> 29:  * @summary test that all fields returned by getDeclaredFields() can be
> 30:  *          set accessible if the right permission is granted; this test
> 31:  *          also verifies that Class.classLoader final private field is

"if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:

> 336: 
> 337:     public static enum TestCase {
> 338:         UNSECURE;

Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:

> 43: 
> 44:     public static void main(String... args) throws Throwable {
> 45:         System.err.println("Test without security manager.");

Security manager is not relevant any more.  Suggest to drop this println.

test/jdk/java/lang/invoke/RevealDirectTest.java line 33:

> 31:  * @test
> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest

line 36 can also be removed.


* $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java line 77:

> 75:             @Override
> 76:             public boolean implies(ProtectionDomain domain, Permission p) {
> 77:                 return perms.implies(p) || DEFAULT_POLICY.implies(domain, p);

static variable `DEFAULT_POLICY` (line 48) can be removed.

test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:

> 81:     }
> 82: 
> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";

This constant is no longer needed.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2383401067
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809627796
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809631220
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811445313
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811458290
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811462419
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809602637

From bpb at openjdk.org  Tue Oct 22 21:45:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 21:45:19 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v5]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <i873XNVLl7N5-C88RFZWG54aKbKt_aESzsvZk0sc9rs=.174ce148-05f2-4a13-9ce9-e7108f9fd646@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

  8233451: Add --enable-native-access=ALL-UNNAMED; clean up formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/ead1b59b..f4ab451b

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

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

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

From bpb at openjdk.org  Tue Oct 22 21:45:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 21:45:20 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
 <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>
Message-ID: <OKVLXCNKBuI3uS3YUHPzfiTY9LxUdy-nIRrsx6RVnVE=.91c4c2b0-b274-4b03-8eb1-98b5ac14a4f5@github.com>

On Tue, 22 Oct 2024 16:22:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

I ran the version of commit f4ab451 30 times on all platforms without failures.

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 29:
>> 
>>> 27:  * @library .. /test/lib
>>> 28:  * @build jdk.test.lib.Platform
>>> 29:  * @run junit InputStreamTest
>> 
>> I think this will need --enable-native-access=ALL-UNNAMED.
>
> It works as is in the CI.

Changed in f4ab451.

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 99:
>> 
>>> 97:                     try {
>>> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
>>> 99:                         {
>> 
>> The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.
>
> Thanks, I'll clean it up.

Cleaned up in f4ab451.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2430365919
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811476591
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811476822

From coleenp at openjdk.org  Wed Oct 23 00:02:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 00:02:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <i_kRTAV64HcQosNOwa19e2Ezu5advIOT9r6KQ9lfRnA=.f2194af6-509c-4cdf-8f29-0b78071114a0@github.com>

On Tue, 22 Oct 2024 19:01:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make lea with RIP-relative addressing more general

> Then I looked at typing up the thread / lock ids as an enum class https://github.com/openjdk/jdk/commit/34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Both of these suggested changes should be discussed as different RFEs.  I don't really like this ThreadID change because it seems to introduce casting everywhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701

From bpb at openjdk.org  Wed Oct 23 00:09:25 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 00:09:25 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

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

  8233451: Added test of readNBytes(int)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/f4ab451b..2876d9fa

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

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

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

From pchilanomate at openjdk.org  Wed Oct 23 00:35:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Address David's comments to ObjectMonitor.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/81e5c6d0..b6bc98e2

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

  Stats: 147 lines in 11 files changed: 10 ins; 7 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Wed Oct 23 00:35:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <ERnhebjKvn3xuNnBLCTfZXgc4ak-2z3Cpl5l5y8K3js=.031eb960-544a-4149-b930-aa37b31b0219@github.com>

On Tue, 22 Oct 2024 06:27:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/objectMonitor.hpp line 47:
> 
>> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 47: // See next_waiter(), first_waiter(), etc.
> 
> This to-do is likely no longer relevant with the current changes.

Removed.

> src/hotspot/share/runtime/objectMonitor.hpp line 288:
> 
>> 286:   // Returns true if this OM has an owner, false otherwise.
>> 287:   bool      has_owner() const;
>> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.
> 
> null is not an int64_t value.

Changed to NO_OWNER.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855

From pchilanomate at openjdk.org  Wed Oct 23 00:41:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:41:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>

On Tue, 22 Oct 2024 06:31:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/objectMonitor.hpp line 292:
> 
>> 290: 
>> 291:   static int64_t owner_for(JavaThread* thread);
>> 292:   static int64_t owner_for_oop(oop vthread);
> 
> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 
> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

> src/hotspot/share/runtime/objectMonitor.hpp line 303:
> 
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 303:   // Simply set _owner field to current; current value must match basic_lock_p.
> 
> Comment is no longer accurate

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:   // _owner field. Returns the prior value of the _owner field.
>> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 
> Similar to set_owner* need better comments describing API.

Added similar comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 311:
> 
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
>> 310: 
>> 311:   bool      is_succesor(JavaThread* thread);
> 
> I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

Right, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 315:
> 
>> 313:   void      set_succesor(oop vthread);
>> 314:   void      clear_succesor();
>> 315:   bool      has_succesor();
> 
> Sorry but `successor` has two `s` before `or`.

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 317:
> 
>> 315:   bool      has_succesor();
>> 316: 
>> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }
> 
> Again `has_owner` seems more appropriate

Yes, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 323:
> 
>> 321:   }
>> 322: 
>> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

I changed it to `has_owner_anonymous`.

> src/hotspot/share/runtime/objectMonitor.hpp line 333:
> 
>> 331:   bool is_stack_locker(JavaThread* current);
>> 332:   BasicLock* stack_locker() const;
>> 333:   void set_stack_locker(BasicLock* locker);
> 
> Again `is` versus `has`, plus some general comments describing the API.

Fixed and added comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601098
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601168
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601545
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601472
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601619
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601871
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811602000

From coleenp at openjdk.org  Wed Oct 23 01:22:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.784030c7-ecc1-4b8f-ae85-cbd2e68304b0@github.com>

On Tue, 22 Oct 2024 19:01:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make lea with RIP-relative addressing more general

I've done a first pass over the first commit and have some comments and questions.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214

From coleenp at openjdk.org  Wed Oct 23 01:22:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
Message-ID: <vc7yb0rPrCsvTFxlSjVuCowEFqyXNl89l6Ls2eVYS4g=.beb72a45-9822-41cd-8b96-ed74a2472532@github.com>

On Tue, 22 Oct 2024 02:09:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
>> 
>>> 378:     lea(t2_owner_addr, owner_address);
>>> 379: 
>>> 380:     // CAS owner (null => current thread id).
>> 
>> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
>> 
>> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)
>
> Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

yes, we preferred lock_id here which is the same as the Java version of thread id, but not the same as the os thread-id.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811583503

From coleenp at openjdk.org  Wed Oct 23 01:22:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>

On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
> 
>> 5339: 
>> 5340: void MacroAssembler::inc_held_monitor_count() {
>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::inc_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Also, is it better to have this without assignment.  Which is a nit.
Address dst(rthread, JavaThread::held_monitor_count_offset());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811584584

From coleenp at openjdk.org  Wed Oct 23 01:22:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:

> 5352:   str(rscratch2, dst);
> 5353:   Label ok;
> 5354:   tbz(rscratch2, 63, ok);

63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2629:

> 2627:   addi(temp, displaced_header, in_bytes(ObjectMonitor::owner_offset()) - markWord::monitor_value);
> 2628:   Register thread_id = displaced_header;
> 2629:   ld(thread_id, in_bytes(JavaThread::lock_id_offset()), R16_thread);

Maybe to make things really clear, you could call this thread_lock_id ?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:

> 229: 
> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());

Address dst(xthread, JavaThread::held_monitor_count_offset());

src/hotspot/share/runtime/javaThread.cpp line 2002:

> 2000: #ifdef SUPPORT_MONITOR_COUNT
> 2001: 
> 2002: #ifdef LOOM_MONITOR_SUPPORT

If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

src/hotspot/share/runtime/objectMonitor.cpp line 416:

> 414:     set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.
> 415:     return true;
> 416:   }

Not needed? Oh I see, BasicLock is now in stack_locker.

src/hotspot/share/runtime/objectMonitor.cpp line 1014:

> 1012:   assert_mark_word_consistency();
> 1013:   UnlinkAfterAcquire(current, currentNode);
> 1014:   if (is_succesor(current)) clear_succesor();

successor has two 's'.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811591482
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811595282
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453

From coleenp at openjdk.org  Wed Oct 23 01:22:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <eXYawRQQVqA8NLFgpPr-H1F1oLdu1Ka-Yk4npkyi298=.8acffd05-cd72-4377-8732-2e453e3181c7@github.com>

On Wed, 23 Oct 2024 00:37:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 315:
>> 
>>> 313:   void      set_succesor(oop vthread);
>>> 314:   void      clear_succesor();
>>> 315:   bool      has_succesor();
>> 
>> Sorry but `successor` has two `s` before `or`.
>
> Fixed.

Yes, need to fix successor spelling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558

From psadhukhan at openjdk.org  Wed Oct 23 03:10:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>

On Tue, 22 Oct 2024 16:44:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.
>
> Agreed. This is not a "clean up / update tests" task.
> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811704257

From psadhukhan at openjdk.org  Wed Oct 23 03:10:32 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <BhXyfrLOvAdzoIDfhbCHSeahv9kA7Yt6g9bTufm394k=.cb3057f8-aeef-42cf-8a23-71602c0531cb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 36:

> 34: import javax.swing.SwingUtilities;
> 35: 
> 36: /*

this here the order is changed...

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 24:

> 22:  */
> 23: 
> 24: /**

again here the import and tag order is changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811705627
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811706135

From psadhukhan at openjdk.org  Wed Oct 23 03:19:28 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:19:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <hBSgrNiQ1XrBiepIl60-kesAatcE7Flw6_cRwQRDIpA=.846ab6c0-0855-4f0d-a9d8-91831587dfae@github.com>

On Tue, 22 Oct 2024 16:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Not specific to JEP 486, this should be done as part of a different issue.
>
> agreed

there were many tests modified in javax_swing in this PR where the author tag is removed, only this is missed so I pointed it out...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811724308

From psadhukhan at openjdk.org  Wed Oct 23 05:14:36 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 05:14:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
> 
>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
> 
>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
> 
>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
> 
>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
> 
> 
> Left out comments that fall into out-of-scope/clean-up for jep486.

looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430919687

From dholmes at openjdk.org  Wed Oct 23 05:21:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:21:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
Message-ID: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>

On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay but ....
>> 1. We have the current virtual thread
>> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
>> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?
>
> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.

Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811877637

From aboldtch at openjdk.org  Wed Oct 23 05:38:11 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:38:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
Message-ID: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>

On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>> 
>>> 2232:     retry_fast_path = true;
>>> 2233:   } else {
>>> 2234:     relativize_chunk_concurrently(chunk);
>> 
>> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
>> 
>> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.
>
> Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

Something along those lines, yes.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
>> 
>>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>>> 2246: 
>>> 2247:     chunk->set_lockstack_size(0);
>> 
>> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
>> 
>> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
>> 
>> 
>> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
>> index d3d63533eed..f737bd2db71 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.cpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
>> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>>    }
>>  }
>>  
>> +void stackChunkOopDesc::clear_lockstack() {
>> +  const int cnt = lockstack_size();
>> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
>> +  const auto clear_obj = [&](intptr_t* at) {
>> +    if (requires_uncompress) {
>> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
>> +    } else {
>> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
>> +    }
>> +  };
>> +
>> +  if (requires_gc_barriers) {
>> +    intptr_t* lockstack_start = start_address();
>> +    for (int i = 0; i < cnt; i++) {
>> +      clear_obj(&lockstack_start[i]);
>> +    }
>> +  }
>> +  set_lockstack_size(0);
>> +  set_has_lockstack(false);
>> +}
>> +
>>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>>    if (*((juint*)this) == badHeapWordVal) {
>>      st->print_cr("BAD WORD");
>> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
>> index 28e0576801e..928e94dd695 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.hpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
>> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>>  
>>    void copy_lo...
>
> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.

It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811903902
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811900946

From dholmes at openjdk.org  Wed Oct 23 05:52:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:52:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

Thanks for those updates.

src/hotspot/share/runtime/objectMonitor.hpp line 299:

> 297:   // Simply set _owner field to new_value; current value must match old_value.
> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 299:   // Same as above but uses tid of current as new value.

By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
> 302:   void      set_owner_from_BasicLock(JavaThread* current);

Shouldn't tid there be the basicLock?

src/hotspot/share/runtime/objectMonitor.hpp line 334:

> 332: 
> 333:   // Returns true if BasicLock* stored in _stack_locker
> 334:   // points to current's stack, false othwerwise.

Suggestion:

  // points to current's stack, false otherwise.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377

From aboldtch at openjdk.org  Wed Oct 23 05:59:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:59:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
Message-ID: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>

On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
>> 
>>> 5339: 
>>> 5340: void MacroAssembler::inc_held_monitor_count() {
>>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>> 
>> Suggestion:
>> 
>> // Clobbers: rscratch1 and rscratch2
>> void MacroAssembler::inc_held_monitor_count() {
>>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>
> Also, is it better to have this without assignment.  Which is a nit.
> Address dst(rthread, JavaThread::held_monitor_count_offset());

The `=` in a variable definition is always construction, never assignment. 

That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811925424

From dholmes at openjdk.org  Wed Oct 23 06:10:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:10:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <7tG1N819A95VfA37K3PK5PejcHkaBPHzWdO6wGA06w0=.10223953-863f-4ca6-ae1b-085112085c3d@github.com>

On Wed, 23 Oct 2024 00:35:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 292:
>> 
>>> 290: 
>>> 291:   static int64_t owner_for(JavaThread* thread);
>>> 292:   static int64_t owner_for_oop(oop vthread);
>> 
>> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?
>
> I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

I like the idea of using `owner_id_from` but it then suggests to me that `JavaThread::_lock_id` should be something like `JavaThread::_monitor_owner_id`. 

The use of `tid` in comments can be confusing when applied to a `JavaThread` as the "tid" there would normally be a reference of its `osThread()->thread_id()" not it's `threadObj()->thread_id()`. I don't have an obviously better suggestion though.

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 
>> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.
>
> I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

old_tid/new_tid works for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087

From dholmes at openjdk.org  Wed Oct 23 06:14:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:14:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>

On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
>> 
>>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>>> 114:      *   WAITING -> WAITED         // waiting on monitor
>>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
>> 
>> Waiting to re-enter the monitor?
>
> yes

Okay so should it say that?

>> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
>> 
>>> 176:     // timed-wait support
>>> 177:     private long waitTimeout;
>>> 178:     private byte timedWaitNonce;
>> 
>> Strange name - what does this mean?
>
> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

Suggestion: `timedWaitCounter` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604

From dholmes at openjdk.org  Wed Oct 23 06:18:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:18:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

> The tid is cached in the JavaThread object under _lock_id. It is set on JavaThread creation and changed on mount/unmount.

Why do we need to cache it? Is it the implicit barriers related to accessing the `threadObj` oop each time?

Keeping this value up-to-date is a part I find quite confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707

From alanb at openjdk.org  Wed Oct 23 06:41:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 06:41:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
Message-ID: <eCawAsDX_owZu-vk5k_vJhSlteriE1Jw6hYK7W9frxY=.894c8f13-a98b-41d6-aad3-925daf2364f6@github.com>

On Wed, 23 Oct 2024 00:09:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Added test of readNBytes(int)

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2387435769

From alanb at openjdk.org  Wed Oct 23 09:56:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 09:56:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
Message-ID: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>

On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
>> 
>> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).
>
> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091

From rrich at openjdk.org  Wed Oct 23 09:56:12 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 23 Oct 2024 09:56:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value.
> 166:   int64_t _lock_id;

Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293

From alanb at openjdk.org  Wed Oct 23 10:01:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:01:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
Message-ID: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>

On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value.
>> 166:   int64_t _lock_id;
> 
> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812385061

From alanb at openjdk.org  Wed Oct 23 10:04:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:04:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.df72d7c2-f9a1-431d-984d-2b99febcbed2@github.com>

On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/javaThread.cpp line 2002:
> 
>> 2000: #ifdef SUPPORT_MONITOR_COUNT
>> 2001: 
>> 2002: #ifdef LOOM_MONITOR_SUPPORT
> 
> If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

LOOM_MONITOR_SUPPORT was only needed when there were ports missing. All 4 are included now so this goes away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812389702

From alanb at openjdk.org  Wed Oct 23 10:09:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:09:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
Message-ID: <ekXIc0jjx_4MlD-GhPzW5S5LA4GARcY2WSXvLmnRl04=.3cc80103-51c0-476b-ac36-9568f0b5cb53@github.com>

On Tue, 22 Oct 2024 15:23:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

There's nothing exposed today to allow custom schedulers. The experiments/explorations going on right now have to be careful to not hold any locks. Throwing if holding a monitor is an option but only it would need to be backed by spec and would also shine light on the issue of j.u.concurrent locks as a carrier might independently hold a lock there too.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431600434

From alanb at openjdk.org  Wed Oct 23 11:35:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:35:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
Message-ID: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>

On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.
>
> Suggestion: `timedWaitCounter` ?

We could rename it to timedWaitSeqNo if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648

From alanb at openjdk.org  Wed Oct 23 11:52:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:52:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
 <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
Message-ID: <EEdxqnOAo9_wdmwyW4F-nsSKR-G1K_Lgy-TQHEfPB74=.38278323-1010-4b56-955e-4ad3fe4b0c91@github.com>

On Mon, 21 Oct 2024 17:20:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.
> 
> Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

I checked the commit in the sandbox and it looks okay. It may be some future maintenance in these micros may do some pruning as aren't too useful now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2431865182

From alanb at openjdk.org  Wed Oct 23 11:57:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:57:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:

> 340:         throws Exception
> 341:     {
> 342:         action.run();

testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812582305

From alanb at openjdk.org  Wed Oct 23 12:01:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>

On Tue, 22 Oct 2024 21:20:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
> 
>> 31:  * @test
>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
> 
> line 36 can also be removed.
> 
> 
> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

hasSM and the code that only runs when true can be deleted too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812587449

From alanb at openjdk.org  Wed Oct 23 12:17:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:17:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:

> 239:         Properties props = System.getProperties();
> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
> 241:         System.setSecurityManager(new SecurityMan());

I assume SecurityMan should be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812614134

From coleenp at openjdk.org  Wed Oct 23 12:47:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:47:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/hotspot/share/prims/jvm.cpp line 1272:

> 1270: 
> 1271: 
> 1272: // Returns the inherited_access_control_context field of the running thread.

There's some code in this file in 
static void trace_class_resolution_impl(Klass* to_class, TRAPS) {

That does this:


    while (!vfst.at_end()) {
      Method* m = vfst.method();
      if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
          !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
          !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
        break;
      }
      last_caller = m;
      vfst.next();
    }


Is this dead code that should be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812677985

From alanb at openjdk.org  Wed Oct 23 12:56:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:56:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
Message-ID: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>

On Wed, 23 Oct 2024 12:44:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/hotspot/share/prims/jvm.cpp line 1272:
> 
>> 1270: 
>> 1271: 
>> 1272: // Returns the inherited_access_control_context field of the running thread.
> 
> There's some code in this file in 
> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
> 
> That does this:
> 
> 
>     while (!vfst.at_end()) {
>       Method* m = vfst.method();
>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>         break;
>       }
>       last_caller = m;
>       vfst.next();
>     }
> 
> 
> Is this dead code that should be removed?

This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812694528

From dfuchs at openjdk.org  Wed Oct 23 13:10:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Oct 2024 13:10:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
Message-ID: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>

On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
> 
>> 340:         throws Exception
>> 341:     {
>> 342:         action.run();
> 
> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812727202

From bpb at openjdk.org  Wed Oct 23 15:59:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 15:59:06 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
Message-ID: <_-6pzdPmIivCoYx6V5LdK3nm-BzF8rPDv4VqhatVygM=.51450c30-f082-45c3-85a5-67ea2363269f@github.com>

On Wed, 23 Oct 2024 00:09:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Added test of readNBytes(int)

30 repeats on all platforms succeeded also after the most recent commit, 2876d9f.

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

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2432715348

From pchilanomate at openjdk.org  Wed Oct 23 17:26:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Rename timedWaitNonce to timedWaitSeqNo
 - Fix comment in Thread.java
 - Clear oops when thawing lockstack + add thaw_lockstack()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/b6bc98e2..e232b7f3

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

  Stats: 77 lines in 5 files changed: 29 ins; 18 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Wed Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <IhkGdT3usE5UZqOTAqS-hBQ2FE_2Lc_2pZK5hM_mkdg=.6ea43f0e-f158-414e-a675-ec9682fac8d8@github.com>

On Mon, 21 Oct 2024 12:32:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename timedWaitNonce to timedWaitSeqNo
>>  - Fix comment in Thread.java
>>  - Clear oops when thawing lockstack + add thaw_lockstack()
>
> src/hotspot/share/oops/stackChunkOop.cpp line 471:
> 
>> 469:     }
>> 470:   }
>> 471: }
> 
> Can we turn these three very similar loops into one? In my opinion, it is easier to parse.
> 
> ```C++
> void stackChunkOopDesc::copy_lockstack(oop* dst) {
>   const int cnt = lockstack_size();
>   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>   const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
>   const auto get_obj = [&](intptr_t* at) -> oop {
>     if (requires_gc_barriers) {
>       if (requires_uncompress) {
>         return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
>       }
>       return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
>     }
>     return *reinterpret_cast<oop*>(at);
>   };
> 
>   intptr_t* lockstack_start = start_address();
>   for (int i = 0; i < cnt; i++) {
>     oop mon_owner = get_obj(&lockstack_start[i]);
>     assert(oopDesc::is_oop(mon_owner), "not an oop");
>     dst[i] = mon_owner;
>   }
> }

Done. I combined it with the oop clearing suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417

From pchilanomate at openjdk.org  Wed Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
 <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.b256c1ad-c2d4-44e8-bc39-3201c5a29481@github.com>

On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?
>
> The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.
> 
> It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

I renamed it to transfer_lockstack() and applied the suggested version with the lambda.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813224287

From kizune at openjdk.org  Wed Oct 23 17:27:42 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 23 Oct 2024 17:27:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <cYDFZ0hXc_bXKTrCftDs1-Xd-Rr4iOpngFb3pB8zi2U=.6d408fe5-63bc-45a3-8ff4-264671975ed1@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Finished reviewing of accessibility (both in com.sun and jdk.javax), jdk.javax.sound and jdk.java.awt.Desktop. Looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2432939145

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>

On Tue, 22 Oct 2024 07:03:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/threadIdentifier.cpp line 30:
> 
>> 28: 
>> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
>> 30: static const int64_t INITIAL_TID = 3;
> 
> Can we express this in terms of those reserved values, or are they inaccessible?

Yes, we could define a new public constant `static const int64_t FIRST_AVAILABLE_TID = 3` (or some similar name) and use it here:


diff --git a/src/hotspot/share/runtime/threadIdentifier.cpp b/src/hotspot/share/runtime/threadIdentifier.cpp
index 60d6a990779..710c3141768 100644
--- a/src/hotspot/share/runtime/threadIdentifier.cpp
+++ b/src/hotspot/share/runtime/threadIdentifier.cpp
@@ -24,15 +24,15 @@

 #include "precompiled.hpp"
 #include "runtime/atomic.hpp"
+#include "runtime/objectMonitor.hpp"
 #include "runtime/threadIdentifier.hpp"

-// starting at 3, excluding reserved values defined in ObjectMonitor.hpp
-static const int64_t INITIAL_TID = 3;
-static volatile int64_t next_thread_id = INITIAL_TID;
+// excluding reserved values defined in ObjectMonitor.hpp
+static volatile int64_t next_thread_id = ObjectMonitor::FIRST_AVAILABLE_TID;

 #ifdef ASSERT
 int64_t ThreadIdentifier::initial() {
-  return INITIAL_TID;
+  return ObjectMonitor::FIRST_AVAILABLE_TID;
 }
 #endif

Or maybe define it as MAX_RESERVED_TID instead, and here we would add one to it.

> src/java.base/share/classes/java/lang/Thread.java line 731:
> 
>> 729: 
>> 730:         if (attached && VM.initLevel() < 1) {
>> 731:             this.tid = 3;  // primordial thread
> 
> The comment before the `ThreadIdentifiers` class needs updating to account for this change.

Fixed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 109:
> 
>> 107:      *
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 
> Should this say something similar to the parked case, about the "yield" being successful?

Since the unmount is triggered from the VM we never call yieldContinuation(), unlike with the PARKING case. In other words, there are no two cases to handle. If freezing the continuation fails, the virtual thread will already block in the monitor code pinned to the carrier, so a state of BLOCKING means freezing the continuation succeeded.

> src/java.base/share/classes/java/lang/VirtualThread.java line 110:
> 
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 
> Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

It means it is scheduled to run again and re-contest for the monitor.

> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
> 
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
> 
> Presumably this one means it acquired the monitor?

Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239314
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239799
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240352

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
Message-ID: <v_7OhzC9sq5rI3jGQjn-W8sPfuqFRlaFWPwvxylxDYM=.f3de1cfd-c8dc-4fbb-8a44-a08e4555905f@github.com>

On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Suggestion: `timedWaitCounter` ?
>
> We could rename it to timedWaitSeqNo if needed.

Ok, renamed to timedWaitSeqNo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667

From honkar at openjdk.org  Wed Oct 23 18:06:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 18:06:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <-GbMPbwNI--hHPZyyPgdU-pOMZh0Z4tZ_tLdbv-LL2E=.1494bfd4-7941-4c2e-af9b-82a29a4b2427@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

@prsadhuk 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud

Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433031866

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <nTh2g7Sw6iv8lfDeUFsAru4vij3UTDzgCvhC8pwp3JU=.4546e9fb-99d9-48f9-8948-c6c1172355ea@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

> @prsadhuk
> 
> > looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud
> 
> Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

I also didn't realise you had "changed" it. I'm finding it very painful to navigate to the related files in this huge PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433046255

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ZLiF5TADkOkZ9p142_bjFkSO5cM4DKmqd7j3mnJxnhs=.2d8f316d-a604-4f17-be07-1a917491d5b3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

I've reviewed all jdk/java/awt and jdk/javax/imageio tests.
I've either commented or proactively fixed in the jep sandbox branch. Or both.
Next sync from there should resolve those.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433048411

From bpb at openjdk.org  Wed Oct 23 18:56:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 18:56:10 GMT
Subject: Integrated: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <cEjhQFNTqxN3w9YXOoseCGi7-uwOxEssKdQab81yRwU=.3bf86fae-46ad-46f5-a666-ad5b6b62c26c@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

This pull request has now been integrated.

Changeset: de92fe37
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de92fe375771315452fc5318abfd228fdd31c454
Stats:     413 lines in 8 files changed: 384 ins; 0 del; 29 mod

8233451: (fs) Files.newInputStream() cannot be used with character special files

Reviewed-by: alanb

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

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

From coleenp at openjdk.org  Wed Oct 23 19:18:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:18:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
Message-ID: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>

On Wed, 23 Oct 2024 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1272:
>> 
>>> 1270: 
>>> 1271: 
>>> 1272: // Returns the inherited_access_control_context field of the running thread.
>> 
>> There's some code in this file in 
>> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
>> 
>> That does this:
>> 
>> 
>>     while (!vfst.at_end()) {
>>       Method* m = vfst.method();
>>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>>         break;
>>       }
>>       last_caller = m;
>>       vfst.next();
>>     }
>> 
>> 
>> Is this dead code that should be removed?
>
> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813400810

From coleenp at openjdk.org  Wed Oct 23 19:25:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:25:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
Message-ID: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.30bd0702-7c5b-4806-babe-fc33027928b9@github.com>

On Wed, 23 Oct 2024 06:15:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why do we need to cache it? Is it the implicit barriers related to accessing the threadObj oop each time?

We cache threadObj.thread_id in JavaThread::_lock_id so that the fast path c2_MacroAssembler code has one less load and code to find the offset of java.lang.Thread.threadId in the code.  Also, yes, we were worried about performance of the barrier in this path.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605

From honkar at openjdk.org  Wed Oct 23 19:41:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 19:41:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
Message-ID: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>

On Mon, 21 Oct 2024 21:12:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
> 
>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>> 75: 
>> 76:         if (args.length > 1) {
> 
> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
> 
> Also the messing around with exceptions at the end of the test is pointless

@prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.

Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2

I'll be rename the test as suggested when I update this test next.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813429265

From honkar at openjdk.org  Wed Oct 23 20:20:35 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 20:20:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
 <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
Message-ID: <vmkpLn9nL1RxwBDfE6plkj6ja6Ks2R7_V355BH4mVGQ=.8b4c1433-acd9-4180-9169-5997f934125b@github.com>

On Wed, 23 Oct 2024 19:38:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
>> 
>>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>>> 75: 
>>> 76:         if (args.length > 1) {
>> 
>> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
>> 
>> Also the messing around with exceptions at the end of the test is pointless
>
> @prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.
> 
> Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2
> 
> I'll be rename the test as suggested when I update this test next.

No changes required for this test. The test was failing due to IDE config issue of tmp dir.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813474346

From pchilanomate at openjdk.org  Wed Oct 23 20:22:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:22:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/e232b7f3..baf7ffab

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

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

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

From pchilanomate at openjdk.org  Wed Oct 23 20:47:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
 <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
Message-ID: <gGm48Cxs1mgNeICqJxSkVYxDdT4gGogR9QP6rIcrDVQ=.093b0c5a-ffbe-44b0-b75b-d480321490b1@github.com>

On Tue, 22 Oct 2024 15:56:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
>> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.
>
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
> 
> Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

I see we are already using rscratch1 in these locking macros so I could change it to use that instead. But looking at all other macros in this file we are already using rscratch1 and rscratch2 too, so I think we would be fine either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813513144

From pchilanomate at openjdk.org  Wed Oct 23 20:47:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
 <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.849e94b4-6aa7-4035-9304-525109dbba4c@github.com>

On Wed, 23 Oct 2024 05:56:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Also, is it better to have this without assignment.  Which is a nit.
>> Address dst(rthread, JavaThread::held_monitor_count_offset());
>
> The `=` in a variable definition is always construction, never assignment. 
> 
> That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

Added comment and fixed dst definition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813514402

From pchilanomate at openjdk.org  Wed Oct 23 20:47:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <1fIoKFEkaZWw0x3eG4cdDbHX_RVga-A6ovBsZnwVgbk=.bc2d26c6-c9a2-4ebe-9e95-9bf9733b947c@github.com>

On Wed, 23 Oct 2024 00:19:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:
> 
>> 5352:   str(rscratch2, dst);
>> 5353:   Label ok;
>> 5354:   tbz(rscratch2, 63, ok);
> 
> 63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

I can remove the check. I don't think it hurts either though. Also we can actually just use rscratch1 in the ASSERT case.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:
> 
>> 229: 
>> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
>> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());
> 
> Address dst(xthread, JavaThread::held_monitor_count_offset());

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648

From pchilanomate at openjdk.org  Wed Oct 23 20:47:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <FmKOCSsujrPLhOUfXlnZeAeUrWiLQLMmseBgvHuWrsA=.fcdb55a8-3bde-407a-a26f-b8515ab7407a@github.com>

On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:
> 
>> 5355: 
>> 5356: void MacroAssembler::dec_held_monitor_count() {
>> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::dec_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813515113

From pchilanomate at openjdk.org  Wed Oct 23 20:47:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>

On Wed, 23 Oct 2024 05:42:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/objectMonitor.hpp line 299:
> 
>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 299:   // Same as above but uses tid of current as new value.
> 
> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449

From pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
Message-ID: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>

On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.
>
> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
> 
> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.

[1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450

From pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
Message-ID: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>

On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
>> 
>> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
> 
> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846

From mullan at openjdk.org  Wed Oct 23 21:57:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 21:57:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
Message-ID: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>

On Wed, 23 Oct 2024 12:14:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
> 
>> 239:         Properties props = System.getProperties();
>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>> 241:         System.setSecurityManager(new SecurityMan());
> 
> I assume SecurityMan should be removed too.

Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813724467

From mullan at openjdk.org  Wed Oct 23 22:21:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 22:21:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <-WUk0E4MRJ1CB84NKT6g7L3pmv-IFpgTnJsrjsjSavA=.53352f0c-6c82-4a45-86c8-b3468c842d9e@github.com>

On Tue, 22 Oct 2024 21:36:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

Thanks for the comprehensive review. I have incorporated all of your comments except for removing the enum from `java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java` which is a bit more involved. I plan on posting an updated PR with these and other changes tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433572062

From bpb at openjdk.org  Thu Oct 24 01:03:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 01:03:37 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java failed
Message-ID: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>

`System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

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

Commit messages:
 - 8338426: Test java/nio/channels/Selector/WakeupNow.java failed

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

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

From bpb at openjdk.org  Thu Oct 24 01:03:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 01:03:37 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <WfNi8v_qLzK3yjVWbw3dQeh3Ddi2StwRlYcK4q1z32I=.c7f56471-20fe-45bb-a018-b9d69501f4a6@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

The validity of using a temporal threshold on elapsed time as a failure criterion, as well as the value of that threshold, are not considered at this time.

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

PR Comment: https://git.openjdk.org/jdk/pull/21674#issuecomment-2433987510

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
 <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
Message-ID: <Q4NNfZ8Vuzy9966oDBrXA3pf4818J5MEL13_l_KLmzQ=.e1697634-4105-4bee-8d20-0a375fd190e8@github.com>

On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.
>
> It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

Pushed a fix to avoid printing the virtual thread tid if we hit that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814186777

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
 <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
Message-ID: <uhUjIm6NwTlveCt80zVVVMHSs2D2aVRo0oGpZfuiKyk=.6f63f256-5046-43ff-b2e1-49fd7602fffd@github.com>

On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 166:
>> 
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporary value.
>>> 166:   int64_t _lock_id;
>> 
>> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.
>
> Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

I extended the comment to mention this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814189388

From pchilanomate at openjdk.org  Thu Oct 24 03:38:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>

On Wed, 23 Oct 2024 05:43:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
> 
> Shouldn't tid there be the basicLock?

So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

> src/hotspot/share/runtime/objectMonitor.hpp line 334:
> 
>> 332: 
>> 333:   // Returns true if BasicLock* stored in _stack_locker
>> 334:   // points to current's stack, false othwerwise.
> 
> Suggestion:
> 
>   // points to current's stack, false otherwise.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix comment in objectMonitor.hpp and javaThread.hpp
 - Skip printing tid when not available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/baf7ffab..03ba6dfb

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

  Stats: 23 lines in 4 files changed: 17 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From dholmes at openjdk.org  Thu Oct 24 05:58:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/share/prims/jvm.cpp line 4012:

> 4010:     }
> 4011:     ThreadBlockInVM tbivm(THREAD);
> 4012:     parkEvent->park();

What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value. Also,
> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread

s/temporary change/temporarily change/

src/java.base/share/classes/java/lang/Object.java line 383:

> 381:             try {
> 382:                 wait0(timeoutMillis);
> 383:             } catch (InterruptedException e) {

I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622

From dholmes at openjdk.org  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
Message-ID: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>

On Wed, 23 Oct 2024 20:22:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

src/java.base/share/classes/java/lang/Thread.java line 654:

> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread

Suggestion:

     * counter is off-heap and shared with the VM to allow it to assign thread

src/java.base/share/classes/java/lang/Thread.java line 655:

> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 655:      * identifiers to non-Java threads.

Why do non-JavaThreads need an identifier of this kind?

src/java.base/share/classes/java/lang/VirtualThread.java line 631:

> 629:         // Object.wait
> 630:         if (s == WAITING || s == TIMED_WAITING) {
> 631:             byte nonce;

Suggestion:

            byte seqNo;

src/java.base/share/classes/java/lang/VirtualThread.java line 948:

> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
> 947:      */
> 948:     private void waitTimeoutExpired(byte nounce) {

I assume you meant `nonce` here, but please change to `seqNo`.

src/java.base/share/classes/java/lang/VirtualThread.java line 952:

> 950:         for (;;) {
> 951:             boolean unblocked = false;
> 952:             synchronized (timedWaitLock()) {

Where is the overall design of the timed-wait protocol and it use of synchronization described?

src/java.base/share/classes/java/lang/VirtualThread.java line 1397:

> 1395: 
> 1396:     /**
> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.

Suggestion:

     * Returns a lock object for coordinating timed-wait setup and timeout handling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814158735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814159210
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814169150
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814170953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814171503
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814172621

From dholmes at openjdk.org  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
Message-ID: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>

On Wed, 23 Oct 2024 17:32:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
>> 
>>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
>> 
>> Presumably this one means it acquired the monitor?
>
> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:

RUNNING -> BLOCKING -> BLOCKED
BLOCKED -> UNBLOCKING -> RUNNABLE

I'm just trying to get a better sense of what we can infer if we see these "transition" states.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283

From dholmes at openjdk.org  Thu Oct 24 05:58:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>

On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
>> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
>> 
>> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491
>
>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>
> Yes.

I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814167842

From dholmes at openjdk.org  Thu Oct 24 06:21:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 06:21:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
Message-ID: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>

On Thu, 24 Oct 2024 03:31:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
>> 
>> Shouldn't tid there be the basicLock?
>
> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:

Before: owner = BasicLock* belonging to current
After: owner = JavaThread* of current

with the new version we have:

Before: owner = ANONYMOUS_OWNER
After: owner = tid of current

so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162

From alanb at openjdk.org  Thu Oct 24 07:06:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:06:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>

On Thu, 24 Oct 2024 02:42:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/Thread.java line 655:
> 
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
>> 655:      * identifiers to non-Java threads.
> 
> Why do non-JavaThreads need an identifier of this kind?

JFR. We haven't changed anything there, just the initial tid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940

From alanb at openjdk.org  Thu Oct 24 07:18:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:18:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
Message-ID: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>

On Wed, 23 Oct 2024 19:15:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.
>
> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814402940

From alanb at openjdk.org  Thu Oct 24 07:51:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:51:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <28R_1poNvjGMa9GI5z5mmudDS_3Kvzq9vJ_0sTpDJpA=.403c90e3-b158-4ccf-9875-7af3ad872d2c@github.com>

On Thu, 24 Oct 2024 05:54:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/prims/jvm.cpp line 4012:
> 
>> 4010:     }
>> 4011:     ThreadBlockInVM tbivm(THREAD);
>> 4012:     parkEvent->park();
> 
> What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

It's very similar to the "Reference Handler" thread. That thread calls into the VM to get the pending-Reference list. Now we have "VirtualThread-unblocker" calling into the VM to get the list of virtual threads to unblock. ObjectMonitor::ExitEpilog will the unpark this thread when the virtual thread successor is on the list to unblock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822

From stefank at openjdk.org  Thu Oct 24 08:11:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 08:11:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/share/runtime/objectMonitor.hpp line 325:

> 323:   }
> 324: 
> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814489387

From alanb at openjdk.org  Thu Oct 24 08:29:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 08:29:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>

On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
>
> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
> 
> RUNNING -> BLOCKING -> BLOCKED
> BLOCKED -> UNBLOCKING -> RUNNABLE
> 
> I'm just trying to get a better sense of what we can infer if we see these "transition" states.

We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084

From azvegint at openjdk.org  Thu Oct 24 09:56:37 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 24 Oct 2024 09:56:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <HoUuHVqcGME8iweQAWbnP6igoSGpoRtK7oX32sXi7fk=.a7ec909b-aa58-477f-bf1a-a9244a49df12@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

java beans changes looks good

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2391943640

From jpai at openjdk.org  Thu Oct 24 11:06:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:06:06 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <JU4OQzzLpZoGLULEr_eEL3KUyTZ_u_IakVfLWzwcl1E=.2fddee62-8fee-4c3c-b53a-d2472ed01d09@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

test/jdk/java/nio/channels/Selector/WakeupNow.java line 66:

> 64:         Selector sel = Selector.open();
> 65:         Pipe p = Pipe.open();
> 66:         p.source().configureBlocking(false);

Hello Brian, is this intentionally being removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21674#discussion_r1814764619

From jpai at openjdk.org  Thu Oct 24 11:10:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:10:05 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <JU4OQzzLpZoGLULEr_eEL3KUyTZ_u_IakVfLWzwcl1E=.2fddee62-8fee-4c3c-b53a-d2472ed01d09@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
 <JU4OQzzLpZoGLULEr_eEL3KUyTZ_u_IakVfLWzwcl1E=.2fddee62-8fee-4c3c-b53a-d2472ed01d09@github.com>
Message-ID: <mJvDZC0ZeIUD15TxuF4qwVjCfO-0d0kMhFF_V_Dad3M=.806f4f92-353e-4d99-9218-4d5bea0a329e@github.com>

On Thu, 24 Oct 2024 11:03:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.
>
> test/jdk/java/nio/channels/Selector/WakeupNow.java line 66:
> 
>> 64:         Selector sel = Selector.open();
>> 65:         Pipe p = Pipe.open();
>> 66:         p.source().configureBlocking(false);
> 
> Hello Brian, is this intentionally being removed?

Looking at this test, this removal appears intentional and it's merely cleaning up unused (and thus irrelevant) `Pipe`. It appears that this was a copy/paste oversight in the original test (even the comment on `test2()` method seems to indicate this `Pipe` was an oversight). So what you did here looks correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21674#discussion_r1814768052

From jpai at openjdk.org  Thu Oct 24 11:10:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:10:04 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <TWFtRQ0xd-y7CUs-ma_1SAx0rEGUUNuBn43xX3Lfn88=.ecf9a8f1-f61d-4712-8d2f-a0fa14a54da7@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

This change to move away from using `System.currentTimeMillis()` in favour of `System.nanoTime()` looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21674#pullrequestreview-2392139457

From coleenp at openjdk.org  Thu Oct 24 11:35:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 11:35:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
Message-ID: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>

On Thu, 24 Oct 2024 07:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.
>
> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814801818

From mullan at openjdk.org  Thu Oct 24 13:19:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 13:19:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
 - Remove println about Security Manager.
 - Remove unused static variable NEW_PROXY_IN_PKG.
 - Remove static variable `DEFAULT_POLICY` and unused imports.
 - Remove hasSM() method and code that calls it, and remove comment about
   running test manually with SM.
 - clientlibs: import order
 - warning-string
 - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
 - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=02
  Stats: 65432 lines in 1867 files changed: 1137 ins; 60545 del; 3750 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <TAjuG-LLpFQjYHfC-K2h0rAynZrqV0ckIViIVvwJB94=.cb21f1de-39bc-4fb6-96a1-861834ccb336@github.com>

On Mon, 21 Oct 2024 22:51:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:
> 
>> 29:  * @summary test that all fields returned by getDeclaredFields() can be
>> 30:  *          set accessible if the right permission is granted; this test
>> 31:  *          also verifies that Class.classLoader final private field is
> 
> "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d8564fa8dd003456b6e313c5e07809999c7d96e1

> test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:
> 
>> 43: 
>> 44:     public static void main(String... args) throws Throwable {
>> 45:         System.err.println("Test without security manager.");
> 
> Security manager is not relevant any more.  Suggest to drop this println.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/002276450e625b66b786fb7eae7256bbcafa7496

> test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";
> 
> This constant is no longer needed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/3dbf684263a75470b85a95b9446a44ceb99c4b3a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815057352
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058036
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815055982

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
 <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
Message-ID: <ZHPRQ0q6AkTrdGKCsX_9xghixEQm8e0qe7UTbqPSCFM=.b57001b8-376f-4e00-9953-64d8bdaeb160@github.com>

On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>> 
>>> 31:  * @test
>>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
>> 
>> line 36 can also be removed.
>> 
>> 
>> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest
>
> hasSM and the code that only runs when true can be deleted too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/559934662119b1372fd831de8be7c97f877e0947

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058738

From alanb at openjdk.org  Thu Oct 24 14:27:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 14:27:15 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <4WsQ3pfCIADHUSF342jyckhFXBGyPP2F_JiPCNn8KEE=.c29c0218-2ed7-42f4-9c91-784a89c6ef82@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

Changing it to use nanoTime is good but I wonder about the reliability of the select(2000) taking >= 1s. This test has a history of being on and off the exclude list several times over the years.

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

PR Comment: https://git.openjdk.org/jdk/pull/21674#issuecomment-2435441963

From alanb at openjdk.org  Thu Oct 24 14:29:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 14:29:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
 <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
Message-ID: <bLyF3XGfyhUtiuOuG0jqnqZtXM0UgzNtZAAZhDyNymM=.cdec18a4-ba4e-4e32-918a-93be3d95fadc@github.com>

On Thu, 24 Oct 2024 11:32:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?
>
> So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

I have the changes to Class/ClassLoader to propose as soon as this JEP integrates. If that can go in quickly then it would remove any concerns in advance of your cleanup to remove the filtering of these frames (although I don't think there is an issue as this code path is conditional based on whether a SM is set).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815107403

From bpb at openjdk.org  Thu Oct 24 15:09:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 15:09:05 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <mJvDZC0ZeIUD15TxuF4qwVjCfO-0d0kMhFF_V_Dad3M=.806f4f92-353e-4d99-9218-4d5bea0a329e@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
 <JU4OQzzLpZoGLULEr_eEL3KUyTZ_u_IakVfLWzwcl1E=.2fddee62-8fee-4c3c-b53a-d2472ed01d09@github.com>
 <mJvDZC0ZeIUD15TxuF4qwVjCfO-0d0kMhFF_V_Dad3M=.806f4f92-353e-4d99-9218-4d5bea0a329e@github.com>
Message-ID: <CokRKlQhE0kZ2ZIOq7xaDla43P-RQsZW9c4z9rlPS4Y=.b71d0ee8-fe75-49e0-b280-54e229832470@github.com>

On Thu, 24 Oct 2024 11:06:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/WakeupNow.java line 66:
>> 
>>> 64:         Selector sel = Selector.open();
>>> 65:         Pipe p = Pipe.open();
>>> 66:         p.source().configureBlocking(false);
>> 
>> Hello Brian, is this intentionally being removed?
>
> Looking at this test, this removal appears intentional and it's merely cleaning up unused (and thus irrelevant) `Pipe`. It appears that this was a copy/paste oversight in the original test (even the comment on `test2()` method seems to indicate this `Pipe` was an oversight). So what you did here looks correct.

Hi @jaikiran . Yes it was unused code intentionally removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21674#discussion_r1815191486

From bpb at openjdk.org  Thu Oct 24 15:12:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 15:12:09 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <4WsQ3pfCIADHUSF342jyckhFXBGyPP2F_JiPCNn8KEE=.c29c0218-2ed7-42f4-9c91-784a89c6ef82@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
 <4WsQ3pfCIADHUSF342jyckhFXBGyPP2F_JiPCNn8KEE=.c29c0218-2ed7-42f4-9c91-784a89c6ef82@github.com>
Message-ID: <nycVINVzFk2NchfxnAnmX1w1RXUjt-MRdjSpNQGQgrY=.4e6df427-cc89-4d37-99f1-d4324a5eed13@github.com>

On Thu, 24 Oct 2024 14:24:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Changing it to use nanoTime is good but I wonder about the reliability of the select(2000) taking >= 1s.

I am not sure about it either, but I thought that with the addition of the time delta to the exception message it might allow some information gathering about failures should they occur.

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

PR Comment: https://git.openjdk.org/jdk/pull/21674#issuecomment-2435564454

From aivanov at openjdk.org  Thu Oct 24 17:26:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:26:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/Desktop.java line 713:

> 711:      * {@code Info.plist}.
> 712:      *
> 713:      * @param printFileHandler handler

Suggestion:

     * @param printFileHandler handler
     *

Can we add a blank line here? It's present in the methods above.

Although there are other places below where it's missing; so not worth worrying.

src/java.desktop/share/classes/java/awt/Font.java line 1612:

> 1610:      * obtained.  The {@code String} value of this property is then
> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}

Suggestion:

     * specification of {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1613:

> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}
> 1613:      * If the specified property is not found then null is returned instead.

Suggestion:

     * If the specified property is not found, null is returned instead.

The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

src/java.desktop/share/classes/java/awt/Font.java line 1780:

> 1778:      * <p>
> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}

Suggestion:

     * {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1781:

> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}
> 1781:      * If the specified property is not found then the {@code font}

Suggestion:

     * If the specified property is not found, the {@code font}

src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:

> 66:      * @throws SecurityException if a security manager exists and its
> 67:      *            {@code checkPermission} method doesn't allow the operation
> 68:      * @see       GraphicsConfiguration

Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

src/java.desktop/share/classes/java/beans/Expression.java line 1:

> 1: /*

Needs copyright year update.

src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:

> 69:      *
> 70:      * @param targetType   the class object of the type to be edited
> 71:      * @param editorClass  the class object of the editor classs

Suggestion:

     * @param editorClass  the class object of the editor class

Typo with an extra ?s?. The line should remain unchanged.

src/java.desktop/share/classes/javax/swing/JTable.java line 6343:

> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
> 6342:      *                           returns <code>true</code>
> 6343:      *          method disallows this thread from creating a print job request

Suggestion:


One more line to remove here.

src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:

> 1: /*

Needs updating the copyright year.

test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:

> 26:   @key headful
> 27:   @bug       6785058
> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.

Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:

> 1: /*

Copyright year needs updating.

test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31:

> 29:  * @library ..
> 30:  * @run main Test7084904
> 31:  * @author Sergey Malenkov

The test below `Test4683761.java` removes the `@author` tag. Should it be removed here?

test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:

> 1: /*

Copyright years need updating.

test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:

> 27:  * @test
> 28:  * @bug 8060027
> 29:  * @run main/othervm ReferenceToNonStaticField

Other tests in the set removed `/othervm`. Is it left intentionally?

test/jdk/java/beans/XMLEncoder/Test4631471.java line 28:

> 26:  * @bug 4631471 6972468
> 27:  * @summary Tests DefaultTreeModel encoding
> 28:  * @run main/othervm Test4631471

Other tests in the set removed `/othervm`. Is it left intentionally?

Looks like this question applies to all tests in `XMLEncoder/` directory.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2392963469
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815168399
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815180719
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815184053
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815185648
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815187240
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815203856
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815290263
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815294333
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815320927
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815330072
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815362826
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815404801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815414445
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815434082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815439684
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815440669

From aivanov at openjdk.org  Thu Oct 24 17:30:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:30:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
Message-ID: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>

On Wed, 23 Oct 2024 02:56:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Agreed. This is not a "clean up / update tests" task.
>> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
>> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.
>
> I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
> In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

Did we agree on that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815457993

From honkar at openjdk.org  Thu Oct 24 18:01:47 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:01:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>

On Thu, 24 Oct 2024 17:16:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 8060027
>> 29:  * @run main/othervm ReferenceToNonStaticField
> 
> Other tests in the set removed `/othervm`. Is it left intentionally?

@aivanov-jdk 
It was missed when -Djava.security.manager=allow was removed. 
Out of curiosity: does it affect the performance of CI testing if tests are run in `/othervm` mode when it is not needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815499279

From honkar at openjdk.org  Thu Oct 24 18:12:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:12:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>

On Thu, 24 Oct 2024 14:55:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
> 
>> 711:      * {@code Info.plist}.
>> 712:      *
>> 713:      * @param printFileHandler handler
> 
> Suggestion:
> 
>      * @param printFileHandler handler
>      *
> 
> Can we add a blank line here? It's present in the methods above.
> 
> Although there are other places below where it's missing; so not worth worrying.

@seanjmullan Can you please advice on some of these src file javadoc related clean-up review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815510916

From rriggs at openjdk.org  Thu Oct 24 18:30:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:30:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.base/share/classes/java/io/FilePermission.java line 71:

> 69:  *
> 70:  * @apiNote
> 71:  * This permission cannot be used for controlling access to resources anymore

The word "anymore" is unnecessary.

src/java.base/share/classes/java/io/SerializablePermission.java line 40:

> 38:  *
> 39:  * @apiNote
> 40:  * This permission cannot be used for controlling access to resources anymore

Unnecessary "anymore"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811333130
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811338244

From rriggs at openjdk.org  Thu Oct 24 18:37:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:37:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
 <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
Message-ID: <WP5Y8HfjmKGYOHZjnGID9Uj3_RcqBwlETVZqhbyLuoY=.b97320ba-8fa4-4ee6-bbeb-4fd9178bc3e8@github.com>

On Wed, 23 Oct 2024 21:54:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
>> 
>>> 239:         Properties props = System.getProperties();
>>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>>> 241:         System.setSecurityManager(new SecurityMan());
>> 
>> I assume SecurityMan should be removed too.
>
> Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

Fix to ExecCommand pushed to the sandbox.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815540092

From coleenp at openjdk.org  Thu Oct 24 19:03:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Can you write a comment what this is doing briefly and why?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:

> 1548: #endif /* ASSERT */
> 1549: 
> 1550:   push_cont_fastpath();

One of the callers of this gives a clue what it does.

  __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about

Why do you do this here?  Oh please more comments...

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:

> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
> 2032:     __ push_cont_fastpath();

We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

src/hotspot/share/runtime/continuation.cpp line 89:

> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
> 88:       if (_target->has_async_exception_condition()) {
> 89:         _failed = false;

This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:

> 1273: 
> 1274:   if (caller.is_interpreted_frame()) {
> 1275:     _total_align_size += frame::align_wiggle;

Please put a comment here about frame align-wiggle.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:

> 1276:   }
> 1277: 
> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);

I also forgot what patch does.  Can you add a comment here too?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:

> 1550:   assert(!cont.is_empty(), "");
> 1551:   // This is done for the sake of the enterSpecial frame
> 1552:   StackWatermarkSet::after_unwind(thread);

Is there a new place for this StackWatermark code?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657:

> 1655: }
> 1656: 
> 1657: template<typename ConfigT, bool preempt>

This function is kind of big, do we really want it duplicated to pass preempt as a template parameter?

src/hotspot/share/runtime/objectMonitor.cpp line 876:

> 874:   // and in doing so avoid some transitions ...
> 875: 
> 876:   // For virtual threads that are pinned do a timed-park instead, to

I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

src/hotspot/share/runtime/objectMonitor.cpp line 2305:

> 2303: }
> 2304: 
> 2305: void ObjectMonitor::Initialize2() {

Can you put a comment why there's a second initialize function?  Presumably after some state is set.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813899129
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814081166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814905064
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815015410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815016232
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815245735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815036910
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877

From coleenp at openjdk.org  Thu Oct 24 19:03:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
Message-ID: <uOEk1wWFaFw278TYc_e7vn63TD7Ym3upyk2Yh7RJIhA=.5f1d73df-e4d9-4220-aa30-5f825bd73bde@github.com>

On Wed, 23 Oct 2024 17:26:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename timedWaitNonce to timedWaitSeqNo
>  - Fix comment in Thread.java
>  - Clear oops when thawing lockstack + add thaw_lockstack()

Round 2.  There are a lot of very helpful comments in the new code to explain what it's doing but I have some requests for some more.  And some questions.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935

From rriggs at openjdk.org  Thu Oct 24 19:23:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:23:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <u1-uOqM_jiV8EcaC7dsfCwCQiUjiQVcgHL2XfvTbXBg=.33981b17-c4df-435d-87fe-b552e2fabbb8@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.io... changes in classes and tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2436170029

From rriggs at openjdk.org  Thu Oct 24 19:43:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:43:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed rmi classes and tests
Reviewed ProcessBuilder, ProcessHandler, and Runtime.exec classes and tests

src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:

> 340:         /*
> 341:          * There is no security manager, so disable access to RMI class
> 342:          * loaders and use the would-de parent instead.

Fix typo "would-de" -> "would-be".

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2393555484
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815601635

From aivanov at openjdk.org  Thu Oct 24 20:26:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:26:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
Message-ID: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>

On Thu, 24 Oct 2024 17:58:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> It was missed when `-Djava.security.manager=allow` was removed.

It wasn't intentional then, was it?

> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?

I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.

Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.

https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49

It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815652996

From aivanov at openjdk.org  Thu Oct 24 20:30:39 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:30:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
Message-ID: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>

On Thu, 24 Oct 2024 18:09:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
>> 
>>> 711:      * {@code Info.plist}.
>>> 712:      *
>>> 713:      * @param printFileHandler handler
>> 
>> Suggestion:
>> 
>>      * @param printFileHandler handler
>>      *
>> 
>> ~~Can we add a blank line here? It's present in the methods above.~~
>> 
>> Although there are other places below where it's missing; _so not worth worrying_.
>
> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

@honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.

If it's worth taking care of, we may submit another bug to address it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815657461

From mullan at openjdk.org  Thu Oct 24 21:00:39 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 21:00:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
 <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
Message-ID: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>

On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.
>
> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.
> 
> If it's worth taking care of, we may submit another bug to address it later.

This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815686941

From pchilanomate at openjdk.org  Thu Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Rename set/has_owner_anonymous to set/has_anonymous_owner
 - Fix comments in javaThread.hpp and Thread.java
 - Rename nonce/nounce to seqNo in VirtualThread class
 - Remove ObjectMonitor::set_owner_from_BasicLock()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/03ba6dfb..c7a82c45

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

  Stats: 66 lines in 10 files changed: 2 ins; 37 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Thu Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <DEan9Tspd0UIgQiYMSha9fLGDa0BLD6wEa2w1en9bmg=.dd579010-ff63-4927-ab2c-5972e178b785@github.com>

On Thu, 24 Oct 2024 02:41:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/Thread.java line 654:
> 
>> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 
> Suggestion:
> 
>      * counter is off-heap and shared with the VM to allow it to assign thread

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906

From honkar at openjdk.org  Thu Oct 24 21:10:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 21:10:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
Message-ID: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>

On Thu, 24 Oct 2024 20:23:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> It was missed when -Djava.security.manager=allow was removed. 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in `/othervm` mode when it is not needed?
>
>> It was missed when `-Djava.security.manager=allow` was removed.
> 
> It wasn't intentional then, was it?
> 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
> 
> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
> 
> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
> 
> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
> 
> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

@aivanov-jdk 
Right, it wasn't intentionally but missed when removing `-Djava.security.manager=allow`.

> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.

Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good to remove, I can probably do a replace-all on beans/XMLEncoder/ folder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815694898

From pchilanomate at openjdk.org  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
 <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
Message-ID: <pTM3f2szGU_CSb0ASohOPwIKQQjLpKyquSrfFjCmpew=.3e7e9e9f-ae59-4a6c-b944-19324445d944@github.com>

On Thu, 24 Oct 2024 06:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.
>
> Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:
> 
> Before: owner = BasicLock* belonging to current
> After: owner = JavaThread* of current
> 
> with the new version we have:
> 
> Before: owner = ANONYMOUS_OWNER
> After: owner = tid of current
> 
> so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

I see your point. I removed this method and had the only caller just call set_owner_from_anonymous() and set_stack_locker(nullptr). There was one other caller in ObjectMonitor::complete_exit() but it was actually not needed so I removed it. ObjectMonitor::complete_exit() is only called today on JavaThread exit to possibly unlock monitors acquired through JNI that where not unlocked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784

From pchilanomate at openjdk.org  Thu Oct 24 21:17:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
Message-ID: <gLdoEBbkdZ34VkSGPRJ9GVsSE3guDPf_s8Rk0eiv6N8=.6b76a553-a3e5-4330-8f24-8ee5647dc9da@github.com>

On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/runtime/objectMonitor.hpp line 325:
> 
>> 323:   }
>> 324: 
>> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

I renamed both `set/has_owner_anonymous` to `set/has_anonymous_owner`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701746

From pchilanomate at openjdk.org  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <K_hfNhC2_eMjYjNAZQbT9dL7pGz7cdcfKas7rSbigbA=.f6ef4f24-3473-47c9-833f-c9158457fdcd@github.com>

On Thu, 24 Oct 2024 05:10:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value. Also,
>> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread
> 
> s/temporary change/temporarily change/

Fixed.

> src/java.base/share/classes/java/lang/Object.java line 383:
> 
>> 381:             try {
>> 382:                 wait0(timeoutMillis);
>> 383:             } catch (InterruptedException e) {
> 
> I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

We jump to `StubRoutines::cont_preempt_stub()`. We need to remove all the frames that were just copied to the heap from the physical stack, and then return to the calling method which will be `Continuation.run`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043

From pchilanomate at openjdk.org  Thu Oct 24 21:17:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
Message-ID: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>

On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>>
>> Yes.
>
> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697084

From pchilanomate at openjdk.org  Thu Oct 24 21:17:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <i2BRCkPmAaFopJCUHlnUjKlaahQbwnifHjvu6GiMh7U=.88f208d9-eb95-464c-860e-0f7eab6d3e7d@github.com>

On Thu, 24 Oct 2024 02:57:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 631:
> 
>> 629:         // Object.wait
>> 630:         if (s == WAITING || s == TIMED_WAITING) {
>> 631:             byte nonce;
> 
> Suggestion:
> 
>             byte seqNo;

Changed to seqNo.

> src/java.base/share/classes/java/lang/VirtualThread.java line 948:
> 
>> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
>> 947:      */
>> 948:     private void waitTimeoutExpired(byte nounce) {
> 
> I assume you meant `nonce` here, but please change to `seqNo`.

Changed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 1397:
> 
>> 1395: 
>> 1396:     /**
>> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.
> 
> Suggestion:
> 
>      * Returns a lock object for coordinating timed-wait setup and timeout handling.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815699934
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312

From dholmes at openjdk.org  Thu Oct 24 22:16:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
Message-ID: <uhNEFqOmOPAUXR5vCaSiMeOvh23OjcpBiUgxjZ5PByU=.6bcb0a5f-e0e1-4ed3-b5d8-b470e2859375@github.com>

On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
>> 
>> RUNNING -> BLOCKING -> BLOCKED
>> BLOCKED -> UNBLOCKING -> RUNNABLE
>> 
>> I'm just trying to get a better sense of what we can infer if we see these "transition" states.
>
> We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305

From dholmes at openjdk.org  Thu Oct 24 22:16:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
Message-ID: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>

On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.
>
> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815762233

From honkar at openjdk.org  Thu Oct 24 22:27:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:27:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <gIwlmNzUQN7CM7jX7Tq5CQkS1Ay_fWsPrZABjIRdHeo=.ba7f210c-8a6a-4e47-9c00-830476aa158b@github.com>

On Thu, 24 Oct 2024 16:35:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:
> 
>> 26:   @key headful
>> 27:   @bug       6785058
>> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.
> 
> Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

Looks like the test was created for SM specific issue - [JDK-6785058](https://bugs.openjdk.org/browse/JDK-6785058). I have deleted the test here https://github.com/openjdk/jdk-sandbox/commit/de0a0f67ef207e1d217c42c312a4378f9f7fa833

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815770344

From honkar at openjdk.org  Thu Oct 24 22:31:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:31:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <C6AQiFYXzD9ov3ZvyWThfp_FUec5f-cLLOyPkqLBeeE=.f3c888ca-d459-44ad-9c18-2329869ffa18@github.com>

On Thu, 24 Oct 2024 16:11:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 6343:
> 
>> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
>> 6342:      *                           returns <code>true</code>
>> 6343:      *          method disallows this thread from creating a print job request
> 
> Suggestion:
> 
> 
> One more line to remove here.

Relevant (w.r.t jep486) javadocs changes have been updated here: https://github.com/openjdk/jdk-sandbox/commit/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815773023

From duke at openjdk.org  Thu Oct 24 23:15:16 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 24 Oct 2024 23:15:16 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
Message-ID: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>

OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.

This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.

Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

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

Commit messages:
 - Simpler version that does not break arm32, hopefully
 - 8343020: SecureDirectoryStream not supported on MacOS

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

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

From bpb at openjdk.org  Thu Oct 24 23:52:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 23:52:06 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

There is no `noreg-*` label on the issue. Is this change covered by an existing test?

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2436530199

From dholmes at openjdk.org  Fri Oct 25 00:14:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 00:14:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <nl9Di_JEDI2KSzXhFfRJxrsz7XXyYOnTW_j_te2ToeU=.8290bee1-1f3f-44a4-b149-ec1cac7eaf28@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.)

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702

From bpb at openjdk.org  Fri Oct 25 01:02:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 01:02:08 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <PaQuD_zepA02nHi_iNjVA0P72jrw-NrCnJchK3PRoxc=.1d5299f8-eb8c-4b5b-8919-667e872fa65c@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

I'm seeing a build failure on macosx-x64 on both my own machine and in the CI:

Error occurred during initialization of boot layer
java.lang.InternalError: java.base not found

The platforms `linux-{aarch64,x64}` and `macosx-aarch64` did not have this problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2436595211

From psadhukhan at openjdk.org  Fri Oct 25 04:57:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 04:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
 <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
Message-ID: <3cbgckSg8DmaAkUalu54f2S9UMmrVrgo7SNQ1Eb1PvM=.a2830527-7ffc-48d2-8191-85c861f30b6f@github.com>

On Thu, 24 Oct 2024 17:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
> 
> Did we agree on that?

Atleast client-dev team did..
See this initial note https://github.com/openjdk/jdk/pull/18414/files#r1534605049
And also in our internal meeting, Phil mentioned if IDE is having issue with this tag order (like collapsing) it's IDE's problem and they should be rectified and we should not change our product code for that..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815994453

From dholmes at openjdk.org  Fri Oct 25 06:09:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 06:09:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

Next batch of comments ...

src/hotspot/share/classfile/javaClasses.cpp line 2082:

> 2080: }
> 2081: 
> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {

Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?

I'm struggling to understand how a thread can already be on this list?

src/hotspot/share/classfile/javaClasses.cpp line 2086:

> 2084:   jboolean vthread_on_list = Atomic::load(addr);
> 2085:   if (!vthread_on_list) {
> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);

It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

src/hotspot/share/code/nmethod.cpp line 711:

> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Suggestion:

  if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
      JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

src/hotspot/share/runtime/objectMonitor.cpp line 132:

> 130: 
> 131: // -----------------------------------------------------------------------------
> 132: // Theory of operations -- Monitors lists, thread residency, etc:

This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage

src/hotspot/share/runtime/objectMonitor.cpp line 1140:

> 1138: }
> 1139: 
> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {

Explanatory comment would be good - thanks.

src/hotspot/share/runtime/objectMonitor.cpp line 1532:

> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
> 1531:     // Virtual thread case.
> 1532:     Trigger->unpark();

So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

src/hotspot/share/runtime/objectMonitor.cpp line 1673:

> 1671: 
> 1672:   ContinuationEntry* ce = current->last_continuation();
> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {

So IIUC this use of `interruptible` would be explained as follows:

// Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
// All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
// this is a regular Object.wait call.

src/hotspot/share/runtime/objectMonitor.cpp line 1698:

> 1696:     // on _WaitSetLock so it's not profitable to reduce the length of the
> 1697:     // critical section.
> 1698: 

Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

src/hotspot/share/runtime/objectMonitor.cpp line 2028:

> 2026:   // First time we run after being preempted on Object.wait().
> 2027:   // Check if we were interrupted or the wait timed-out, and in
> 2028:   // that case remove ourselves from the _WaitSet queue.

I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

src/hotspot/share/runtime/objectMonitor.cpp line 2054:

> 2052:   // Mark that we are at reenter so that we don't call this method again.
> 2053:   node->_at_reenter = true;
> 2054:   assert(!has_owner(current), "invariant");

The position of this assert seems odd as it seems to be something that should hold at entry to this method.

src/hotspot/share/runtime/objectMonitor.hpp line 174:

> 172: 
> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor

Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

src/hotspot/share/runtime/objectMonitor.hpp line 207:

> 205: 
> 206:   static void Initialize();
> 207:   static void Initialize2();

Please add comment why this needs to be deferred - and till after what?

src/hotspot/share/runtime/objectMonitor.hpp line 312:

> 310:   void      set_successor(JavaThread* thread);
> 311:   void      set_successor(oop vthread);
> 312:   void      clear_successor();

Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

src/hotspot/share/runtime/objectMonitor.hpp line 349:

> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }

This no longer looks correct if the waiter is a vthread. ??

src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:

> 108: }
> 109: 
> 110: // Returns null if DEFLATER_MARKER is observed.

Comment needs updating

src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:

> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
> 129: // This accessor is called when we really need to know if the owner
> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.

Comment needs updating

src/hotspot/share/runtime/synchronizer.cpp line 670:

> 668:   // Top native frames in the stack will not be seen if we attempt
> 669:   // preemption, since we start walking from the last Java anchor.
> 670:   NoPreemptMark npm(current);

Don't we still pin for JNI monitor usage?

src/hotspot/share/runtime/synchronizer.cpp line 1440:

> 1438: }
> 1439: 
> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {

`inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

src/hotspot/share/runtime/synchronizer.hpp line 172:

> 170: 
> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.

Comment needs updating

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815838204
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815839094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815985700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815998417
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816002660
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816009160
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816014286
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816017269
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816018848
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815956322
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815960013
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815967260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815969101
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816043275
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816047142
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816041444

From psadhukhan at openjdk.org  Fri Oct 25 06:43:42 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 06:43:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <8Oq38NBheXvpvw7sKy_5vSHd7o5r2rJmM8lQToaXmDc=.d8488397-1c79-446b-95c9-9b7a43d4b308@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed jdk javax/print and javax/swing..Looks good..

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437002459

From alanb at openjdk.org  Fri Oct 25 07:12:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 07:12:10 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <tJ2dQGa9SB4u-SZmorIkWQkz0P6rNLaluYiM40XIQNY=.bf5d9360-358e-442b-8e23-b05692db7f95@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21674#pullrequestreview-2394397073

From alanb at openjdk.org  Fri Oct 25 07:12:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 07:12:10 GMT
Subject: RFR: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <nycVINVzFk2NchfxnAnmX1w1RXUjt-MRdjSpNQGQgrY=.4e6df427-cc89-4d37-99f1-d4324a5eed13@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
 <4WsQ3pfCIADHUSF342jyckhFXBGyPP2F_JiPCNn8KEE=.c29c0218-2ed7-42f4-9c91-784a89c6ef82@github.com>
 <nycVINVzFk2NchfxnAnmX1w1RXUjt-MRdjSpNQGQgrY=.4e6df427-cc89-4d37-99f1-d4324a5eed13@github.com>
Message-ID: <Yk1th6YiDSWc_icyyfrfSsKznmds04Kp-22VovAHQlk=.a5dd8a35-e155-4441-8901-bd758a96594e@github.com>

On Thu, 24 Oct 2024 15:09:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Changing it to use nanoTime is good but I wonder about the reliability of the select(2000) taking >= 1s.
> 
> I am not sure about it either, but I thought that with the addition of the time delta to the exception message it might allow some information gathering about failures should they occur.

I don't know which clock source is used by GetQueuedCompletionStatus but I agree, using nanoTimes would be better here and if it fails because it takes <1s then it at least tells us something.

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

PR Comment: https://git.openjdk.org/jdk/pull/21674#issuecomment-2437056814

From alanb at openjdk.org  Fri Oct 25 08:20:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 08:20:05 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
Message-ID: <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>

On Thu, 24 Oct 2024 23:49:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> There is no `noreg-*` label on the issue. Is this change covered by an existing test?

DirectoryStream/SecureDS.java is the test for this API. Right now it only runs on Linux (it used to run on Solaris too).  If support is extended to macOS then we'll need to change this test to use `@requires` and drop the existing check in the test main.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437178133

From alanb at openjdk.org  Fri Oct 25 09:03:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 09:03:04 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <PaQuD_zepA02nHi_iNjVA0P72jrw-NrCnJchK3PRoxc=.1d5299f8-eb8c-4b5b-8919-667e872fa65c@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <PaQuD_zepA02nHi_iNjVA0P72jrw-NrCnJchK3PRoxc=.1d5299f8-eb8c-4b5b-8919-667e872fa65c@github.com>
Message-ID: <9aE6dby0vh03T205CT34n6RBt3p2DASJ0cp160XHMYM=.bb7506db-cccd-4532-9be5-6539162e55e7@github.com>

On Fri, 25 Oct 2024 00:59:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I'm seeing a build failure on macosx-x64 on both my own machine and in the CI:
> 
> ```
> Error occurred during initialization of boot layer
> java.lang.InternalError: java.base not found
> ```

Can you add `-Xlog:init=debug` to see if it reveals anything? In principal it should be okay switch from ftimes_a



> I'm seeing a build failure on macosx-x64 on both my own machine and in the CI:
> 
> ```
> Error occurred during initialization of boot layer
> java.lang.InternalError: java.base not found
> ```

Can you see if -Xlog:init=debug to see if it reveals anything?

I have a vague memory of issues futimes not being supported on some versions of macOS or Linux and we had to use futimesat instead. Switching to futimes means testing on a wide range of OS releases to make sure that aren't any issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437263289

From alanb at openjdk.org  Fri Oct 25 09:19:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 09:19:07 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <9aE6dby0vh03T205CT34n6RBt3p2DASJ0cp160XHMYM=.bb7506db-cccd-4532-9be5-6539162e55e7@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <PaQuD_zepA02nHi_iNjVA0P72jrw-NrCnJchK3PRoxc=.1d5299f8-eb8c-4b5b-8919-667e872fa65c@github.com>
 <9aE6dby0vh03T205CT34n6RBt3p2DASJ0cp160XHMYM=.bb7506db-cccd-4532-9be5-6539162e55e7@github.com>
Message-ID: <bfrCWR2E4goliFHTcpiiFMGjRciLjkEsQIbs6gqYL-U=.a750aa62-d511-4218-ab09-2b0b0fdd45bb@github.com>

On Fri, 25 Oct 2024 09:00:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you see if -Xlog:init=debug to see if it reveals anything?

I was able to duplicate this, it does break the macosx-x64 build, I think it means tracking down which macOS versions have futimes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437297291

From alanb at openjdk.org  Fri Oct 25 10:24:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 10:24:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
 <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
Message-ID: <bIj9x7QeQeCoCgHy7PkpwOy0SLdF2lRnZ8oKN7yjILk=.4f23be55-161c-46f9-b3b7-86ae1426fbb6@github.com>

On Thu, 24 Oct 2024 22:13:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.
>
> Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

We've had these temporary transitions from day 1. The changes in this PR remove one usage, they don't add any new usages. The intention is to make this nuisance go away. The last usage requires changes to the timer support, working on it. For now, it's easiest to think of it as a "java on java" issue where critical code is in Java rather than the VM. The timer issue arises when a virtual thread does a timed park needs to schedule and cancel a timer. This currently requires executing Java code that may contend on a timer or trigger a timer thread to start. This has implications for thread state, the park blocker, and the parking permit. Adding support for nested parking gets very messy, adds overhead, and is confusing for serviceability observers.  The exiting behavior is to just temporarily switch the thread identity (as in Thread::currentThread) so it executes in the context of the carrier rather than the virtual thread. As I said, we are working to make this go away, it would have 
 been nice to have removed in advance of the changes here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590

From psadhukhan at openjdk.org  Fri Oct 25 11:19:41 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <N9SCzjHG3Q-GHIk6nNj7s8_vQBkx_dirVhnTjhWpWw0=.d298d7d7-4fab-46e7-9f07-f4f39f308478@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2394343323

From dfuchs at openjdk.org  Fri Oct 25 11:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <XK2j-0yrasFNv7xEkGgkrwWX09OJD29pcQPMmVd88kU=.13059532-b236-45bf-b788-626491003998@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

For the record I had a look at the changes in JMX and JNDI tests and these look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437522137

From duke at openjdk.org  Fri Oct 25 11:23:06 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 11:23:06 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
 <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>
Message-ID: <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>

On Fri, 25 Oct 2024 08:17:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > There is no `noreg-*` label on the issue. Is this change covered by an existing test?
> 
> DirectoryStream/SecureDS.java is the test for this API. Right now it only runs on Linux (it used to run on Solaris too). If support is extended to macOS then we'll need to change this test to use `@requires` and drop the existing check in the test main.

OK I'll see if I can figure out how to do this.



> > I'm seeing a build failure on macosx-x64 on both my own machine and in the CI:
> > ```
> > Error occurred during initialization of boot layer
> > java.lang.InternalError: java.base not found
> > ```
> 
> Can you see if -Xlog:init=debug to see if it reveals anything?
> 
> I have a vague memory of issues futimes not being supported on some versions of macOS or Linux and we had to use futimesat instead. Switching to futimes means testing on a wide range of OS releases to make sure that aren't any issues.

Luckily I still have a x64 mac so I can test this locally too.  I think `futimesat` is only supported on Linux and Solaris, at least according to https://www.gnu.org/software/gnulib/manual/html_node/futimesat.html if that can be trusted. So I think what's been happening is that `my_futimesat` has been `null` on most platforms, meaning that AFAICT, SDS is simply not available outside of Linux (and Solaris, I guess).

I can also try and see if `utimensat` works better, or even support `futimesat` if present and otherwise fallback to `futimes` and see how that goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437529269

From aivanov at openjdk.org  Fri Oct 25 11:38:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 11:38:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
 <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
Message-ID: <xmvA-xWfN2PbFLJsskbi8HNSDlJ6ANEKeWuzLgqlzrk=.b2eb7e3f-4f25-4c3e-b5c0-e29705ab9ce4@github.com>

On Thu, 24 Oct 2024 21:06:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> It was missed when `-Djava.security.manager=allow` was removed.
>> 
>> It wasn't intentional then, was it?
>> 
>>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
>> 
>> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
>> 
>> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
>> 
>> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
>> 
>> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.
>
> @aivanov-jdk 
> Right, it wasn't intentional but missed when removing `-Djava.security.manager=allow`.
> 
>> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.
> 
> Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good idea to remove it, I could do a find and replace-all on beans/XMLEncoder/ test folder.

@honkar-jdk I've submitted [JDK-8343062](https://bugs.openjdk.org/browse/JDK-8343062) for additional cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816521679

From coleenp at openjdk.org  Fri Oct 25 12:03:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 12:03:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>

On Fri, 25 Oct 2024 03:51:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/share/runtime/objectMonitor.hpp line 174:
> 
>> 172: 
>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
> 
> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.


$ grep -r JFR_THREAD_ID
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

> src/hotspot/share/runtime/synchronizer.cpp line 1440:
> 
>> 1438: }
>> 1439: 
>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
> 
> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

If it's always the current thread, then it should be called 'current' imo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794

From duke at openjdk.org  Fri Oct 25 12:39:10 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 12:39:10 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <Mm18fzSjNWKvVTrYk79Wlnf0BRg0jj1Ke-t9iOmf7Qg=.1349e1b0-2261-45cd-9502-b6ade6ead8af@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

The debug output is not revealing much (the boot module finder just returns `null` for `java.base`), and it seems to be failing too early to attach a debugger, so I'm on to `println` debugging now.

Another logical discrepancy is that `futimes` does in fact seem to work in my standalone `test.c` testing. And anyway, why does boot depend on `futimes`? So I think the problem may be unrelated to `futimes` per se, but rather is due to another capability that is used by `SecureDirectoryStream` that is indirectly enabled. So I'm focusing my high tech debugging strategy in that area as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437667577

From duke at openjdk.org  Fri Oct 25 12:48:05 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 12:48:05 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <7BMWKZJB5x9wr41_nfTg1gb0BFyBWC8JSy0KNFpAJj0=.aec1b3bd-e856-4dba-8f20-4b54bd4cf31b@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

There's an unexpected plot twist. It turns out there's some kind of off-by-one problem when reading the directory when SDS is active. So the exceptions being thrown are like:


java.nio.file.NoSuchFileException: /Volumes/Case-sensitive/Users/david/src/java/openjdk/build/macosx-x86_64-server-release/jdk/modules/ava.management.rmi
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113)
	at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:56)
	at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:163)
	at java.base/java.nio.file.Files.readAttributes(Files.java:1865)
	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:279)
	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:233)
	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:191)
	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:155)
	at java.base/jdk.internal.module.SystemModuleFinders$1.lambda$find$0(SystemModuleFinders.java:217)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)


AFAICT this is coming out of `UnixNativeDispatcher#readdir0` so now I'm digging into that.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437684233

From pchilanomate at openjdk.org  Fri Oct 25 13:17:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
Message-ID: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>

On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add comments for Coleen
>>  - Fix JvmtiUnmountBeginMark
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Can you write a comment what this is doing briefly and why?

Added comment.

> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
> 
>> 1548: #endif /* ASSERT */
>> 1549: 
>> 1550:   push_cont_fastpath();
> 
> One of the callers of this gives a clue what it does.
> 
>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
> 
> Why do you do this here?  Oh please more comments...

_cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
> 
>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>> 2032:     __ push_cont_fastpath();
> 
> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

> src/hotspot/share/runtime/continuation.cpp line 89:
> 
>> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
>> 88:       if (_target->has_async_exception_condition()) {
>> 89:         _failed = false;
> 
> This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

Yes, good catch.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
> 
>> 1273: 
>> 1274:   if (caller.is_interpreted_frame()) {
>> 1275:     _total_align_size += frame::align_wiggle;
> 
> Please put a comment here about frame align-wiggle.

I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:
> 
>> 1276:   }
>> 1277: 
>> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);
> 
> I also forgot what patch does.  Can you add a comment here too?

I added a comment where it is defined since it is used in several places.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:
> 
>> 1550:   assert(!cont.is_empty(), "");
>> 1551:   // This is done for the sake of the enterSpecial frame
>> 1552:   StackWatermarkSet::after_unwind(thread);
> 
> Is there a new place for this StackWatermark code?

I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

> src/hotspot/share/runtime/objectMonitor.cpp line 876:
> 
>> 874:   // and in doing so avoid some transitions ...
>> 875: 
>> 876:   // For virtual threads that are pinned do a timed-park instead, to
> 
> I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 2305:
> 
>> 2303: }
>> 2304: 
>> 2305: void ObjectMonitor::Initialize2() {
> 
> Can you put a comment why there's a second initialize function?  Presumably after some state is set.

Added comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816658344
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660817
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661388
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661733
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662247
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065

From pchilanomate at openjdk.org  Fri Oct 25 13:17:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add comments for Coleen
 - Fix JvmtiUnmountBeginMark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/c7a82c45..0308ee4c

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

  Stats: 22 lines in 6 files changed: 10 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From mullan at openjdk.org  Fri Oct 25 13:47:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 13:47:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>

On Tue, 22 Oct 2024 20:23:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
> 
>> 38:  *
>> 39:  * @apiNote
>> 40:  * This permission cannot be used for controlling access to resources anymore
> 
> Unnecessary "anymore"

Removed this word from all `Permission` subclasses; fix will be in next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816717534

From duke at openjdk.org  Fri Oct 25 13:51:04 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 13:51:04 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <syibCqAoWhKeyYhXVk3XWiGkn7R0Ju8XEaR5ihDzDzw=.0dc4688e-6c3f-46fe-8bfe-6316069431cf@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

After a lot of `printf` I'm closer to a diagnosis/solution:

* `fdopendir` is returning a valid pointer
* `readdir0` is using the same pointer, so nothing is being lost there
* `readdir` is returning entries which appear to be 4-byte aligned, so I think that's valid
* However the `dirent`'s `d_name` field is consistently offset by 15 bytes, which is kind of weird (but not really, because `char` usually has one byte alignment), and that does seem to be the correct struct member offset
* And, the first character of the directory name is definitely there, but at offset -1 from `d_name`, which is definitely screwy
* So what's the common thread? A test program using `fdopendir` works fine. But: if I load `fdopendir` using `dlsym`, now I have the off-by-one problem. So perhaps we're somehow getting a wrong or broken `fdopendir`. Further testing being done.

I'm getting close!

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2437832210

From bpb at openjdk.org  Fri Oct 25 15:39:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 15:39:13 GMT
Subject: Integrated: 8338426: Test java/nio/channels/Selector/WakeupNow.java
 failed
In-Reply-To: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
References: <Hj7HqlNdiPf7fBhP8kmms2HAwGJShg6TjVDAQJDtdg0=.7969c5d4-77a2-40b0-81fc-b295968154f2@github.com>
Message-ID: <BkkdG1xJmDBEuRxvXtEs-uuHjfQlGpibI3p1lHxWyvc=.56174da9-adaf-43f5-86ff-cabf484dc64e@github.com>

On Thu, 24 Oct 2024 00:58:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `System.currentTimeMillis()` is replaced with `System.nanoTime()` and the elapsed time is added to the failure exception message.

This pull request has now been integrated.

Changeset: 0853aee3
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0853aee3b377cf9f17340a85f600651db42e6999
Stats:     15 lines in 1 file changed: 4 ins; 2 del; 9 mod

8338426: Test java/nio/channels/Selector/WakeupNow.java failed

Reviewed-by: jpai, alanb

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

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

From bpb at openjdk.org  Fri Oct 25 15:43:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 15:43:06 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
 <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>
 <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>
Message-ID: <jlpVKNDApsxZKahHT3GbM4Lb8qqmVXZKwMGfwQD8bRw=.0f2fa498-356f-46a4-b56f-6697751e0d27@github.com>

On Fri, 25 Oct 2024 11:20:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> DirectoryStream/SecureDS.java is the test for this API.

I found that after posting my question.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438156558

From duke at openjdk.org  Fri Oct 25 16:10:20 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 16:10:20 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS [v2]
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <EHjOCAqxIZFBHveIcIyvITn8bliqR99ephl8Bvnun04=.3f6512e3-d83e-46cd-a02e-04141cc10e30@github.com>

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Use 64-bit variation when 64-bit inodes are detected on macos x86

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21696/files
  - new: https://git.openjdk.org/jdk/pull/21696/files/8bb31fdc..4572704b

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

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

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

From duke at openjdk.org  Fri Oct 25 16:10:20 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 16:10:20 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <YblmmRofxjMJAX7eLPo-BDeklia3NM5L_qatGgACJaI=.49b4450a-5743-4a42-a63e-7c8ea6f8d980@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

OK the new version doesn't use `dlsym` on Mac OS for `openat`, `fstatat`, and `fdopendir`, all of which have different CPU-dependent names. This is the simplest change I could think of that solves the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438221589

From michaelm at openjdk.org  Fri Oct 25 16:11:46 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Oct 2024 16:11:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TJNWAEiPXYUxNLNQSveRSSTbV6KUK2aDTjUBN-V-Q9M=.97954e4d-05d7-480a-94a6-ca283458596d@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've reviewed the networking tests and they look fine. There are tests that possibly don't need the `othervm` keyword any more, and some tests that still do permission implies tests (without a security manager) but these can be updated independently in future PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438222428

From duke at openjdk.org  Fri Oct 25 16:47:06 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 16:47:06 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
 <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>
 <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>
Message-ID: <WqmJehpCBbzKyR2hXXpKKVRakq-CSe5LL6-brGPS228=.42f60dd2-6110-4f51-9ba0-e5a51d99e4a5@github.com>

On Fri, 25 Oct 2024 11:20:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> > There is no `noreg-*` label on the issue. Is this change covered by an existing test?
> 
> DirectoryStream/SecureDS.java is the test for this API. Right now it only runs on Linux (it used to run on Solaris too). If support is extended to macOS then we'll need to change this test to use `@requires` and drop the existing check in the test main.

I think the existing test will work still, because I don't see anything that restricts the OS, and the `instanceof` test should return `true` now on macos, right?

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438301131

From duke at openjdk.org  Fri Oct 25 16:52:04 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 16:52:04 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS
In-Reply-To: <WqmJehpCBbzKyR2hXXpKKVRakq-CSe5LL6-brGPS228=.42f60dd2-6110-4f51-9ba0-e5a51d99e4a5@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <a2htvZcc1r-ebmlue2dBtb9TV5RHWlpaxLymM1NFyI0=.599f9319-5627-45e6-a471-2559d76a870d@github.com>
 <15XmAA93Ecrk44ul9f8d8W4ZNu86TwvJOZcJzNX67t0=.9e387c65-8a1b-4261-bc1b-1d705b2c626b@github.com>
 <iacEHsC6onghkfMIlo3-DvN-3i-xe_joRaB6jdfGm4M=.54871006-3109-4c2a-93ff-397efbfc872b@github.com>
 <WqmJehpCBbzKyR2hXXpKKVRakq-CSe5LL6-brGPS228=.42f60dd2-6110-4f51-9ba0-e5a51d99e4a5@github.com>
Message-ID: <rhZro_W1N2XEr70CkrnmL4J2Kk4BeN8opbYaC5W8zsw=.2de22412-d75c-42d5-ac60-edf62c671178@github.com>

On Fri, 25 Oct 2024 16:44:08 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> > > There is no `noreg-*` label on the issue. Is this change covered by an existing test?
> > 
> > 
> > DirectoryStream/SecureDS.java is the test for this API. Right now it only runs on Linux (it used to run on Solaris too). If support is extended to macOS then we'll need to change this test to use `@requires` and drop the existing check in the test main.
> 
> I think the existing test will work still, because I don't see anything that restricts the OS, and the `instanceof` test should return `true` now on macos, right?

Never mind, I see: it will pass if everything is working, but it will also pass on macos if it's not working. So, I'll go ahead and make that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438312311

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:

> 1: /*

I believe this test becomes irrelevant without `SecurityManager`.

The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:

> 1: /*

I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.

If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.

The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 44:

> 42:     private static JFrame frame;
> 43:     private static JPopupMenu popupMenu;
> 44:     private static volatile boolean isAlwaysOnTop1 = false;

Suggestion:

    private static volatile boolean isAlwaysOnTop = false;

There's only one flag now, it needs no modifier.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 54:

> 52: 
> 53:             SwingUtilities.invokeAndWait(bug6691503::testApplication);
> 54:             robot.delay(200);

The additional delay is redundant.

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:

> 39:  * @bug 6694823
> 40:  * @summary Checks that popup menu cannot be partially hidden
> 41:  *          by the task bar.

I believe this test is irrelevant without the security manager.

The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.

Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:

> 1: /*

Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.

Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395179909
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816616064
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816806950
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816827134
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816826424
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816840082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816896526

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>

On Fri, 25 Oct 2024 15:12:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
> 
>> 1: /*
> 
> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
> 
> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.

Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.

However, a more thorough analysis is required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816923550

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
Message-ID: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>

On Fri, 25 Oct 2024 15:29:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
>> 
>>> 1: /*
>> 
>> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
>> 
>> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.
>
> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
> 
> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
> 
> However, a more thorough analysis is required.

The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817034884

From duke at openjdk.org  Fri Oct 25 16:58:42 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 25 Oct 2024 16:58:42 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS [v3]
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.

David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:

 - Add bug ID to test
 - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21696/files
  - new: https://git.openjdk.org/jdk/pull/21696/files/4572704b..6167680e

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

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

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

From bpb at openjdk.org  Fri Oct 25 16:58:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 16:58:42 GMT
Subject: RFR: 8343020: SecureDirectoryStream not supported on MacOS [v2]
In-Reply-To: <EHjOCAqxIZFBHveIcIyvITn8bliqR99ephl8Bvnun04=.3f6512e3-d83e-46cd-a02e-04141cc10e30@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <EHjOCAqxIZFBHveIcIyvITn8bliqR99ephl8Bvnun04=.3f6512e3-d83e-46cd-a02e-04141cc10e30@github.com>
Message-ID: <AALP88DS1iXO0x9kTUjXj9ARosLFeaU_SpOsLCayC2I=.4c7b2e46-342e-462b-9153-ec0bc8e3c6d9@github.com>

On Fri, 25 Oct 2024 16:10:20 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 64-bit variation when 64-bit inodes are detected on macos x86

I think you will need to add the issue ID to the `@bug` tag of the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438323175

From mchung at openjdk.org  Fri Oct 25 17:29:17 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 25 Oct 2024 17:29:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
Message-ID: <FkxtznpxqChlt5BT4JAL3tkjv7vJu-QBC7sBeCg8wQc=.24c36c93-0ed3-4e9f-84c7-4c286df12603@github.com>

On Fri, 25 Oct 2024 13:17:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments for Coleen
>  - Fix JvmtiUnmountBeginMark

I looked at java.lang.ref and java.lang.invoke changes.   ReferenceQueue was reverted back to use synchronized and also adding the code disable/enable preemption looks right.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438401789

From honkar at openjdk.org  Fri Oct 25 17:33:44 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 17:33:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>

On Fri, 25 Oct 2024 14:57:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
> 
>> 39:  * @bug 6694823
>> 40:  * @summary Checks that popup menu cannot be partially hidden
>> 41:  *          by the task bar.
> 
> I believe this test is irrelevant without the security manager.
> 
> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
> 
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817093001

From aivanov at openjdk.org  Fri Oct 25 17:56:43 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 17:56:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
Message-ID: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>

On Fri, 25 Oct 2024 17:30:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
>> 
>>> 39:  * @bug 6694823
>>> 40:  * @summary Checks that popup menu cannot be partially hidden
>>> 41:  *          by the task bar.
>> 
>> I believe this test is irrelevant without the security manager.
>> 
>> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
>> 
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.
>
> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.

The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.

> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.

The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817116860

From bpb at openjdk.org  Fri Oct 25 18:03:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 18:03:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
Message-ID: <ZjehOI9RwnlCQfoK6WlUYkqoqU3nW6c8f80l0pSZ1YQ=.26e7c29b-5864-45f2-9d37-0eabdbd235b7@github.com>

On Fri, 25 Oct 2024 13:17:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments for Coleen
>  - Fix JvmtiUnmountBeginMark

The `InternalLock` and `ByteArrayOutputStream` changes look all right. I'll follow up with [JDK-8343039](https://bugs.openjdk.org/browse/JDK-8343039) once this PR for [JEP 491](https://openjdk.org/jeps/491) is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438461962

From aivanov at openjdk.org  Fri Oct 25 18:12:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:12:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:

> 40:         } catch (ServiceConfigurationError sce) {
> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
> 42:             System.out.println("Test Passed");

Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438514238
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817159883

From pchilanomate at openjdk.org  Fri Oct 25 18:34:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:34:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add/fix comments for David
 - Move condition to new line in nmethod::preserve_callee_argument_oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0308ee4c..d6313cf7

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

  Stats: 20 lines in 6 files changed: 14 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From honkar at openjdk.org  Fri Oct 25 18:36:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 18:36:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
Message-ID: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>

On Fri, 25 Oct 2024 17:52:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>
> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> 
> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
> 
>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
> 
> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
> 
> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

@aivanov-jdk 
On macOS, popup is shifted up and does not cover the taskbar even without SM. 

> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817183611

From pchilanomate at openjdk.org  Fri Oct 25 18:39:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:39:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>

On Thu, 24 Oct 2024 03:01:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
> 
>> 950:         for (;;) {
>> 951:             boolean unblocked = false;
>> 952:             synchronized (timedWaitLock()) {
> 
> Where is the overall design of the timed-wait protocol and it use of synchronization described?

When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381

From pchilanomate at openjdk.org  Fri Oct 25 18:50:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>

On Fri, 25 Oct 2024 00:26:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>
Yes.

> src/hotspot/share/classfile/javaClasses.cpp line 2086:
> 
>> 2084:   jboolean vthread_on_list = Atomic::load(addr);
>> 2085:   if (!vthread_on_list) {
>> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);
> 
> It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

The same example mentioned above, with a different timing, could result in two threads trying to add the same virtual thread to the list at the same time.

> src/hotspot/share/code/nmethod.cpp line 711:
> 
>> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> Suggestion:
> 
>   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
>       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 1140:
> 
>> 1138: }
>> 1139: 
>> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {
> 
> Explanatory comment would be good - thanks.

Added comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1532:
> 
>> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
>> 1531:     // Virtual thread case.
>> 1532:     Trigger->unpark();
> 
> So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

Right.

> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
> 
>> 2026:   // First time we run after being preempted on Object.wait().
>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>> 2028:   // that case remove ourselves from the _WaitSet queue.
> 
> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

> src/hotspot/share/runtime/objectMonitor.cpp line 2054:
> 
>> 2052:   // Mark that we are at reenter so that we don't call this method again.
>> 2053:   node->_at_reenter = true;
>> 2054:   assert(!has_owner(current), "invariant");
> 
> The position of this assert seems odd as it seems to be something that should hold at entry to this method.

Ok, I moved it to the beginning of resume_operation.

> src/hotspot/share/runtime/objectMonitor.hpp line 207:
> 
>> 205: 
>> 206:   static void Initialize();
>> 207:   static void Initialize2();
> 
> Please add comment why this needs to be deferred - and till after what?

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 312:
> 
>> 310:   void      set_successor(JavaThread* thread);
>> 311:   void      set_successor(oop vthread);
>> 312:   void      clear_successor();
> 
> Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 349:
> 
>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
> 
> This no longer looks correct if the waiter is a vthread. ??

It is, we still increment _waiters for the vthread case.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:
> 
>> 108: }
>> 109: 
>> 110: // Returns null if DEFLATER_MARKER is observed.
> 
> Comment needs updating

Updated.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:
> 
>> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
>> 129: // This accessor is called when we really need to know if the owner
>> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.
> 
> Comment needs updating

Updated. Removed the second sentence, seemed redundant.

> src/hotspot/share/runtime/synchronizer.cpp line 670:
> 
>> 668:   // Top native frames in the stack will not be seen if we attempt
>> 669:   // preemption, since we start walking from the last Java anchor.
>> 670:   NoPreemptMark npm(current);
> 
> Don't we still pin for JNI monitor usage?

Only when facing contention on this call. But once we have the monitor we don't.

> src/hotspot/share/runtime/synchronizer.hpp line 172:
> 
>> 170: 
>> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
>> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.
> 
> Comment needs updating

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817192967
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195264
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195487
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196602
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817197017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200025
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200202
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195731
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195899
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200860
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200711

From pchilanomate at openjdk.org  Fri Oct 25 18:50:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>

On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2082:
>> 
>>> 2080: }
>>> 2081: 
>>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {
>> 
>> Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>> 
>> I'm struggling to understand how a thread can already be on this list?
>
>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>
> Yes.

> Some comments here about the operation would be useful.
>
Added a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817193493

From pchilanomate at openjdk.org  Fri Oct 25 18:50:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
Message-ID: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>

On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>>
>> Yes.
>
>> Some comments here about the operation would be useful.
>>
> Added a comment.

> I'm struggling to understand how a thread can already be on this list?
>
With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817194346

From pchilanomate at openjdk.org  Fri Oct 25 18:50:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <4W0X1OrNe43nsePtODBGt0aBs3LNJYaCMhJsPslI-7U=.710243ff-55af-4166-80de-48824662dd68@github.com>

On Fri, 25 Oct 2024 05:25:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add/fix comments for David
>>  - Move condition to new line in nmethod::preserve_callee_argument_oops
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1698:
> 
>> 1696:     // on _WaitSetLock so it's not profitable to reduce the length of the
>> 1697:     // critical section.
>> 1698: 
> 
> Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

Restored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027

From aivanov at openjdk.org  Fri Oct 25 18:55:38 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
Message-ID: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>

On Fri, 25 Oct 2024 18:30:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> 
>> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
>> 
>>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>> 
>> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
>> 
>> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.
>
> @aivanov-jdk 
> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
> 
>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:

https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902

On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.

At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.

I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.

Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.

Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817205444

From bpb at openjdk.org  Fri Oct 25 19:44:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 19:44:05 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
Message-ID: <LvQxd0dqLaJMtDYJrL2MnAtDQo8BA3021cfptItJaaA=.953117c2-8051-44c9-978a-01d5a6a17be3@github.com>

On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

The build now succeeds and the test passes on macOS-x64. Testing of other platforms is in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2438663267

From weijun at openjdk.org  Fri Oct 25 19:49:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 19:49:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Comments on `java.security` classes.

Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

I also reviewed files in `conf/security`. Everything looks fine except for the `networkaddress.cache.ttl` security property which still references the Security Manager.

src/java.base/share/classes/java/security/AccessControlContext.java line 32:

> 30: 
> 31: /**
> 32:  * AccessControlContext was used with a SecurityManager for access control decisions

I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

src/java.base/share/classes/java/security/AccessControlContext.java line 141:

> 139:         throws AccessControlException
> 140:     {
> 141:         throw new AccessControlException("");

No message for this exception?

src/java.base/share/classes/java/security/AccessControlException.java line 29:

> 27: 
> 28: /**
> 29:  *

Add a sentence like "This was..."?

src/java.base/share/classes/java/security/Policy.java line 90:

> 88:  *       and subject to removal in a future release. Consequently, this class
> 89:  *       is also deprecated and subject to removal. There is no replacement for
> 90:  *       the Security Manager or this class.

Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

src/java.base/share/classes/java/security/Policy.java line 374:

> 372:      *
> 373:      * @param codesource the CodeSource to which the returned
> 374:      *          PermissionCollection has been granted

Can we say this parameter is ignored? I see some other methods said so.

Same with the other `getPermissions` and `implies`.

src/java.base/share/classes/java/security/SecureClassLoader.java line 1:

> 1: /*

The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?

src/java.base/share/classes/java/security/Security.java line 489:

> 487: 
> 488:     /**
> 489:      * Adds a provider to the next position available..

Two periods at the end.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395870667
PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438672204
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817189896
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817193883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817194616
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817163586
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817173742
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817050537
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817042605

From honkar at openjdk.org  Fri Oct 25 20:34:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 20:34:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>

On Fri, 25 Oct 2024 14:36:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
> 
>> 1: /*
> 
> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
> 
> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
> 
> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085

Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817311600

From rriggs at openjdk.org  Fri Oct 25 21:04:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:04:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java/util/* and corresponding tests.
Logging tests should refactor to eliminate use of doPrivileged(fn);

test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:

> 50: import com.foo.NumberFormatProviderImpl;
> 51: 
> 52: public class PermissionTest{

This test can be deleted entirely. What remains is just constructing each provider impl.
The summary mentions a RuntimePermission and would need to be revised to a new description.

test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:

> 46:             throw new RuntimeException("unexpected resource bundle");
> 47:         }
> 48: 

This main and TestPermission.java duplicate the basic resource location mechanisms.
This test/Main.java an test/TestPermission can be removed entirely.

test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:

> 26:  * @bug 6552961 6558429
> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
> 28:  * @run main PrivilegedCallables

There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:

> 155:     static class Configure {
> 156:         static void setUp(Properties propertyFile) {
> 157:             doPrivileged(() -> {

The doPrivileged() could be factored out.
And callPrivileged().

test/jdk/java/util/logging/FileHandlerPath.java line 149:

> 147:     static class Configure {
> 148:         static void setUp(Properties propertyFile) {
> 149:             doPrivileged(() -> {

doPrivileged() could be refactored; it is no longer necessary.

test/jdk/java/util/logging/FileHandlerPatternExceptions.java line 106:

> 104:     static class Configure {
> 105:         static void setUp(Properties propertyFile) {
> 106:             doPrivileged(() -> {

doPrivileged() is no longer necessary.

test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:

> 38:  * @modules java.base/jdk.internal.access
> 39:  *          java.logging
> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet

Rename these?  What's really being tested, there are no more Applets.

test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:

> 81:      * then the test is considered a success and passes.
> 82:      *
> 83:      * Note that 4sec may not be enough to detect issues if there are some.

Where is this timeout enforced or measured; this is just a comment, not a parameter.

test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:

> 123:     }
> 124: 
> 125:     @Benchmark

Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2396279786
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817269899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817285899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817291039
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817304993
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817307433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817310090
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817323513
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327555
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817352471

From honkar at openjdk.org  Fri Oct 25 21:12:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:12:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>

On Fri, 25 Oct 2024 18:08:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
> 
>> 40:         } catch (ServiceConfigurationError sce) {
>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>> 42:             System.out.println("Test Passed");
> 
> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 

When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
has been updated to expect ServiceConfigurationError.

AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
> 
>> 1: /*
> 
> I believe this test becomes irrelevant without `SecurityManager`.
> 
> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
I can update the test summary accordingly  -
 **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**

@azuev-java Your thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817371084
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817373529

From mullan at openjdk.org  Fri Oct 25 21:21:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 21:21:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
Message-ID: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>

On Fri, 25 Oct 2024 19:44:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Yes, good point, let me review the class again and see if we can remove some more text or make some adjustments.

> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
> 
>> 30: 
>> 31: /**
>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
> 
> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
> 
>> 139:         throws AccessControlException
>> 140:     {
>> 141:         throw new AccessControlException("");
> 
> No message for this exception?

I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

> src/java.base/share/classes/java/security/AccessControlException.java line 29:
> 
>> 27: 
>> 28: /**
>> 29:  *
> 
> Add a sentence like "This was..."?

You mean move the first sentence of the deprecated text to here?

> src/java.base/share/classes/java/security/Policy.java line 90:
> 
>> 88:  *       and subject to removal in a future release. Consequently, this class
>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>> 90:  *       the Security Manager or this class.
> 
> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

> src/java.base/share/classes/java/security/Policy.java line 374:
> 
>> 372:      *
>> 373:      * @param codesource the CodeSource to which the returned
>> 374:      *          PermissionCollection has been granted
> 
> Can we say this parameter is ignored? I see some other methods said so.
> 
> Same with the other `getPermissions` and `implies`.

Yes, good suggestion.

> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 

Yes I think we can remove that text.

> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?

You mean a warning like we have in the `Permission` subclasses?

`URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

> src/java.base/share/classes/java/security/Security.java line 489:
> 
>> 487: 
>> 488:     /**
>> 489:      * Adds a provider to the next position available..
> 
> Two periods at the end.

Will fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438893608
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327704
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817335403
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817344307
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817362628
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817348142
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817377926
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817314475

From honkar at openjdk.org  Fri Oct 25 21:27:51 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
Message-ID: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>

On Fri, 25 Oct 2024 16:47:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
>> 
>> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
>> 
>> However, a more thorough analysis is required.
>
> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

@prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817385564

From rriggs at openjdk.org  Fri Oct 25 21:27:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <MjiRdWwmMhjnUXIIeDkclBTTnKBLsbxdZzHk-r69OaA=.c8ddefea-bd18-4ed7-8e2a-700860c2f99e@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.compiler and corresponding langtools/tools/ tests. lgtm

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438900946

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Restore use of atPointA in test StopThreadTest.java
 - remove interruptible check from conditional in Object::wait

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/d6313cf7..66d5385f

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

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

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

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <_Tc64RU3Q9TuPgc7ThXZGyW7pRCfoTIJKsqbEfyrFzs=.618f372b-d250-4aed-b7ab-31e1061aec8f@github.com>

On Fri, 25 Oct 2024 05:17:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1673:
> 
>> 1671: 
>> 1672:   ContinuationEntry* ce = current->last_continuation();
>> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {
> 
> So IIUC this use of `interruptible` would be explained as follows:
> 
> // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
> // All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
> // this is a regular Object.wait call.

Yes, although the non-interruptible call is coming from ObjectLocker, which already has the NoPreemptMark, so I removed this check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817388840

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
Message-ID: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>

On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1440:
>> 
>>> 1438: }
>>> 1439: 
>>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
>> 
>> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?
>
> If it's always the current thread, then it should be called 'current' imo.

I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389380

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
Message-ID: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>

On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If it's always the current thread, then it should be called 'current' imo.
>
> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

> If it's always the current thread, then it should be called 'current' imo.
>
The inflating thread is always the current one but it's not always equal to `inflating_thread`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389882

From dlong at openjdk.org  Fri Oct 25 22:12:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 22:12:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
Message-ID: <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>

On Fri, 25 Oct 2024 18:34:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add/fix comments for David
>  - Move condition to new line in nmethod::preserve_callee_argument_oops

test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:

> 28:  *         by reflection API
> 29:  * @library /test/lib/
> 30:  * @requires vm.compMode != "Xcomp"

If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638

From coleenp at openjdk.org  Fri Oct 25 22:39:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

Some more comments and questions on the latest commit, mostly minor.

src/hotspot/share/interpreter/oopMapCache.cpp line 268:

> 266:   }
> 267: 
> 268:   int num_oops() { return _num_oops; }

I can't find what uses this from OopMapCacheEntry.

src/hotspot/share/runtime/objectMonitor.cpp line 1150:

> 1148:     if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) {
> 1149:       assert(_recursions == 0, "invariant");
> 1150:       set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.

This is nice you don't have to do this anymore.

src/hotspot/share/runtime/objectMonitor.hpp line 43:

> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 43: // See next_waiter(), first_waiter(), etc.

Also a nice cleanup.  Did you reconcile the JVMTI code?

src/hotspot/share/runtime/objectMonitor.hpp line 71:

> 69:   bool is_wait()           { return _is_wait; }
> 70:   bool notified()          { return _notified; }
> 71:   bool at_reenter()        { return _at_reenter; }

should these be const member functions?

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817407075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817419797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420178

From dlong at openjdk.org  Fri Oct 25 22:39:19 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 22:39:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <K0Dq341ibU2CPv8QKU5yMm4WzR8RYk7fU1qvJ5ShZRs=.b67219d8-b08f-42ba-b007-f3bdb6407349@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:

> 189:   // must restore the rfp value saved on enter though.
> 190:   if (use_pop) {
> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));

leave() also calls authenticate_return_address(), which I assume we still want to call here.
How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321

From coleenp at openjdk.org  Fri Oct 25 22:39:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>
Message-ID: <mHKxi5OLZX0oPMqn6app9G5OQcbaOYlcHvumIufOXZQ=.8ce900f0-4c58-4687-a5e9-fca9853ca62d@github.com>

On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 299:
>> 
>>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 299:   // Same as above but uses tid of current as new value.
>> 
>> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?
>
> It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

but we can't change it there to thread_id because then it would be too confusing.  Since it's used for locking, lock_id seems like a good name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420867

From prr at openjdk.org  Fri Oct 25 22:44:40 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:44:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <tSwEN61gdo0zlJ-Wsw2DRIx1yD_dTIp596vpnWdm0nY=.24b18dd6-e549-4ae1-8638-da8993c22962@github.com>

On Fri, 25 Oct 2024 21:06:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
>> 
>>> 40:         } catch (ServiceConfigurationError sce) {
>>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>>> 42:             System.out.println("Test Passed");
>> 
>> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?
>
> When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 
> 
> When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
> has been updated to expect ServiceConfigurationError.
> 
> AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

Yes, perhaps there's some more general test for this in java.base, but there's nothing wrong with verifying it here, even though it is sort of backward from what the test previously verified.
Probably the test could always have tested both cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817428928

From prr at openjdk.org  Fri Oct 25 22:55:38 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
Message-ID: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>

On Fri, 25 Oct 2024 21:23:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.
>
> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
But I don't see a problem with keeping the rest of the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817433603

From dlong at openjdk.org  Fri Oct 25 23:06:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:06:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <1KPMXYDDC_St1ngjVzSecyHuxoc42y48ykFAKsgmHQs=.68d68376-6a29-46cb-9cac-eea0ccefcc24@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Suggestion:

  f.interpreter_frame_set_last_sp(f.unextended_sp());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593

From dlong at openjdk.org  Fri Oct 25 23:10:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:10:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <5oXp0uwV-tbPCuHPe7Z6czcA24uOxbf0Fm99ArCYT2g=.2c44eb24-e6f5-48fa-ac55-936b1d85aa16@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:

> 131: 
> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");

Suggestion:

  assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076

From dlong at openjdk.org  Fri Oct 25 23:14:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:14:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <ud9bGNgGiRVjQiJkBRz8Sw3xKOe7JKVtYLn8aJfLc7o=.b7d44099-cc5f-4ed5-8048-0561c654a7b8@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:

> 157: 
> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).

Suggestion:

  // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).

Isn't that 2 words, not 3?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437

From bpb at openjdk.org  Fri Oct 25 23:20:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 23:20:04 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
Message-ID: <LceKk1mAAuZWbtjNVI9ehnerl5FXaSJ0St_iUmyAndY=.06593d91-4cc4-41d1-a61c-3d0f42fafb86@github.com>

On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

Build and test succeeded on `Linux-{aarch64,x64}`, `macOS-{aarch64,x64}`, and `Windows-x64`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2439032550

From kizune at openjdk.org  Fri Oct 25 23:23:37 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 25 Oct 2024 23:23:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>

On Fri, 25 Oct 2024 21:09:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
>> 
>>> 1: /*
>> 
>> I believe this test becomes irrelevant without `SecurityManager`.
>> 
>> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).
>
> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
> I can update the test summary accordingly  -
>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
> 
> @azuev-java Your thoughts?

That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817444639

From coleenp at openjdk.org  Fri Oct 25 22:39:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
Message-ID: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>

On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.
>
>> If it's always the current thread, then it should be called 'current' imo.
>>
> The inflating thread is always the current one but it's not always equal to `inflating_thread`.

I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817423564

From bpb at openjdk.org  Fri Oct 25 23:31:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 23:31:08 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
Message-ID: <tc4d3_T4MPIbckxrrP8j4Oj6eI183hbI6YSK3n3WLrU=.f6355ef9-224b-46ac-a4a7-86270e06360a@github.com>

On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

Approved. Please do not integrate until @AlanBateman has also approved, thanks.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21696#pullrequestreview-2396701237

From weijun at openjdk.org  Fri Oct 25 23:47:43 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 23:47:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>

On Fri, 25 Oct 2024 20:53:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
>> 
>>> 139:         throws AccessControlException
>>> 140:     {
>>> 141:         throw new AccessControlException("");
>> 
>> No message for this exception?
>
> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

I see. Maybe this is enough.

>> src/java.base/share/classes/java/security/AccessControlException.java line 29:
>> 
>>> 27: 
>>> 28: /**
>>> 29:  *
>> 
>> Add a sentence like "This was..."?
>
> You mean move the first sentence of the deprecated text to here?

Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452658

From weijun at openjdk.org  Sat Oct 26 00:01:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 26 Oct 2024 00:01:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>

On Fri, 25 Oct 2024 21:14:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/SecureClassLoader.java line 1:
>> 
>>> 1: /*
>> 
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?
>
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
> 
> Yes I think we can remove that text.
> 
>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
> 
> You mean a warning like we have in the `Permission` subclasses?
> 
> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.

On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817457008

From dlong at openjdk.org  Sat Oct 26 00:06:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:06:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
Message-ID: <jiLbxr6TkMLG8JgH0CHhoJpkggmJZjyxoWVBLU8Frgk=.d3c668c3-adf5-4fb6-88c4-75b710e8f6f8@github.com>

On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
>> 
>>> 298:   CodeBlob* cb = top.cb();
>>> 299: 
>>> 300:   if (cb->frame_size() == 2) {
>> 
>> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.
>
> We could also check the caller of the runtime frame, something like:
> 
> #ifdef ASSERT
>   RegisterMap map(JavaThread::current(),
>                   RegisterMap::UpdateMap::skip,
>                   RegisterMap::ProcessFrames::skip,
>                   RegisterMap::WalkContinuation::skip);
>   frame caller = top.sender(&map);
>   assert(caller.is_compiled_frame(), "");
>   assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
> #endif
> 
> Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

I agree, checking for frame_size() == 2 seems fragile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817458483

From dlong at openjdk.org  Sat Oct 26 00:20:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:20:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:

> 186:   // Avoid using a leave instruction when this frame may
> 187:   // have been frozen, since the current value of rfp
> 188:   // restored from the stub would be invalid. We still

It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936

From dlong at openjdk.org  Sat Oct 26 00:30:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:30:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:

> 308:     sp -= 2;
> 309:     sp[-2] = sp[0];
> 310:     sp[-1] = sp[1];

This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371

From dlong at openjdk.org  Sat Oct 26 00:33:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:33:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:

> 336:   // Make sure that extended_sp is kept relativized.
> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()

Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037

From dlong at openjdk.org  Sat Oct 26 01:45:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:45:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:

> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 1554:   adr(rscratch1, resume_pc);
> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));

Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:

> 1565: 
> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
> 1567:   bind(resume_pc);

If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657

From dlong at openjdk.org  Sat Oct 26 01:54:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:54:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:

> 117:   return  mask.num_oops()
> 118:         + 1 // for the mirror oop
> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot

Where is this temp oop slot set and used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144

From dlong at openjdk.org  Sat Oct 26 01:57:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:57:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:

> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
> 3795:   __ testbool(rscratch1);
> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);

If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633

From dlong at openjdk.org  Sat Oct 26 02:01:18 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 02:01:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
Message-ID: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
> 
>> 308:     sp -= 2;
>> 309:     sp[-2] = sp[0];
>> 310:     sp[-1] = sp[1];
> 
> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

Could the problem be solved with a resume adapter instead, like the interpreter uses?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817556946

From dlong at openjdk.org  Sat Oct 26 02:18:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 02:18:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

> On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.

During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub.  In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320

From alanb at openjdk.org  Sat Oct 26 05:42:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Oct 2024 05:42:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
 <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>
Message-ID: <_BwEZ3vYJTCgODZ_cvAQ49Vz00neenp7mMxrPo7jg-8=.60dab023-3df4-4533-bd6d-89dace99d65a@github.com>

On Fri, 25 Oct 2024 22:09:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add/fix comments for David
>>  - Move condition to new line in nmethod::preserve_callee_argument_oops
>
> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:
> 
>> 28:  *         by reflection API
>> 29:  * @library /test/lib/
>> 30:  * @requires vm.compMode != "Xcomp"
> 
> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430

From rrich at openjdk.org  Sat Oct 26 06:54:16 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 06:54:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
Message-ID: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>

On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
> 
>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 1554:   adr(rscratch1, resume_pc);
>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
> 
> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

Its indeed difficult to see how the value is propagaged. I think it goes like this:

- read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
- copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
- Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
- Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702223

From rrich at openjdk.org  Sat Oct 26 06:59:19 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 06:59:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
Message-ID: <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>

On Sat, 26 Oct 2024 01:42:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
> 
>> 1565: 
>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>> 1567:   bind(resume_pc);
> 
> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.

At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986

From rrich at openjdk.org  Sat Oct 26 07:07:20 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 07:07:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
Message-ID: <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>

On Sat, 26 Oct 2024 01:54:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
> 
>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>> 3795:   __ testbool(rscratch1);
>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
> 
> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994

From duke at openjdk.org  Sun Oct 27 14:25:07 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 27 Oct 2024 14:25:07 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
 [v2]
In-Reply-To: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
Message-ID: <Xlul5m5LH7lFRGZCbvguVCz7beaLc0SRMkbtgGHLnyc=.ce24f0ec-38ed-4e6a-8f6b-081c05f6819e@github.com>

> # Targets
> 
> The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
> 
> A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.
> 
> An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.
> 
> 
> # Non-Targets
> 
> It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
> 
> It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.
> 
> It is not a target to improve other source types besides pipes and sockets.
> 
> 
> # Description
> 
> What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.
> 
> For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.
> 
> Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.
> 
> 
> # Implementation
> 
> The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.
> 
> Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
> 1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
> 2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferred from the source into the OS kernel, nor from the OS kernel into n...

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

  Socket.getInputStream()'s JavaDocs explain behavior of skip for timeout, non-blocking, interrupt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20489/files
  - new: https://git.openjdk.org/jdk/pull/20489/files/1525444c..ecc32c1f

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

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

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

From duke at openjdk.org  Sun Oct 27 15:22:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 27 Oct 2024 15:22:15 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
 [v2]
In-Reply-To: <Xlul5m5LH7lFRGZCbvguVCz7beaLc0SRMkbtgGHLnyc=.ce24f0ec-38ed-4e6a-8f6b-081c05f6819e@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <Xlul5m5LH7lFRGZCbvguVCz7beaLc0SRMkbtgGHLnyc=.ce24f0ec-38ed-4e6a-8f6b-081c05f6819e@github.com>
Message-ID: <GDylhjGNXs7EA45vkuJ9WCIRvEs8UndywihQacZOrtQ=.c151e1fd-8016-4fa7-a739-af82a7de1e73@github.com>

On Sun, 27 Oct 2024 14:25:07 GMT, Markus KARG <duke at openjdk.org> wrote:

>> # Targets
>> 
>> The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
>> 
>> A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.
>> 
>> An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.
>> 
>> 
>> # Non-Targets
>> 
>> It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
>> 
>> It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.
>> 
>> It is not a target to improve other source types besides pipes and sockets.
>> 
>> 
>> # Description
>> 
>> What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.
>> 
>> For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.
>> 
>> Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.
>> 
>> 
>> # Implementation
>> 
>> The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.
>> 
>> Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
>> 1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
>> 2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferr...
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Socket.getInputStream()'s JavaDocs explain behavior of skip for timeout, non-blocking, interrupt

>...this method doesn't specify how show skip behaves when a timeout is set, doesn't specify IllegalBlockingModeException when the channel is non-blocking, and doesn't specify how it behaves when the Thread is interrupted.
> In addition to skip, the other methods that may be implemented with more than one read are the transferTo, readAllBytes, readNBytes, ... all methods added since JDK 1.0. It may be that Socket's class level description or the setSoTimeout method will need wording to say that it is implementation specific as to how the configured timeout works with these methods. It may apply to the entire operation, or each read operation when implemented with multiple reads, tricky to word.
>
> The issue of skip or any of the other methods throwing IllegalBlockingModeException can probably be confined to the Socket.getInputStream's API docs where it already documents this exception as possible when reading.

Alan, sorry for being silent for weeks. I was bound in other projects.

To keep things simple, I now have added wording just for `skip`, ignoring the fact that several of other methods are missing specs, too. Looking at the class-level docs, I did not find anything to change. `skip`'s behavior is now found in the very places where `read`'s is found, which makes sense, as its implementation (besides the C-loops and using `splice` instead of `read`) is mostly a copy of `read`'s.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2440064191

From dholmes at openjdk.org  Mon Oct 28 00:29:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:29:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
Message-ID: <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>

On Fri, 25 Oct 2024 18:36:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
>> 
>>> 950:         for (;;) {
>>> 951:             boolean unblocked = false;
>>> 952:             synchronized (timedWaitLock()) {
>> 
>> Where is the overall design of the timed-wait protocol and it use of synchronization described?
>
> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

Thanks for the explanation but that needs to be documented somewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510

From dholmes at openjdk.org  Mon Oct 28 00:34:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:34:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
Message-ID: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.9a170591-0b33-4424-8e01-09f39d936273@github.com>

On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 174:
>> 
>>> 172: 
>>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
>> 
>> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??
>
> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.
> 
> 
> $ grep -r JFR_THREAD_ID
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
> runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
> runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
> runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543

From dholmes at openjdk.org  Mon Oct 28 00:34:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:34:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>

On Fri, 25 Oct 2024 18:42:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 349:
>> 
>>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
>> 
>> This no longer looks correct if the waiter is a vthread. ??
>
> It is, we still increment _waiters for the vthread case.

Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368

From dholmes at openjdk.org  Mon Oct 28 00:41:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:41:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>

On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> If it's always the current thread, then it should be called 'current' imo.
>>>
>> The inflating thread is always the current one but it's not always equal to `inflating_thread`.
>
> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240440

From dholmes at openjdk.org  Mon Oct 28 00:41:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:41:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>

On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
>> 
>>> 2026:   // First time we run after being preempted on Object.wait().
>>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>>> 2028:   // that case remove ourselves from the _WaitSet queue.
>> 
>> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.
>
> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

The first sentence is not a sentence. Is it supposed to be saying:

// The first time we run after being preempted on Object.wait()
// we check if we were interrupted or the wait timed-out ...

?

>> src/hotspot/share/runtime/synchronizer.cpp line 670:
>> 
>>> 668:   // Top native frames in the stack will not be seen if we attempt
>>> 669:   // preemption, since we start walking from the last Java anchor.
>>> 670:   NoPreemptMark npm(current);
>> 
>> Don't we still pin for JNI monitor usage?
>
> Only when facing contention on this call. But once we have the monitor we don't.

But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818239594
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013

From dholmes at openjdk.org  Mon Oct 28 00:47:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:47:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
Message-ID: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>

On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Some comments here about the operation would be useful.
>>>
>> Added a comment.
>
>> I'm struggling to understand how a thread can already be on this list?
>>
> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015

From dholmes at openjdk.org  Mon Oct 28 01:02:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:02:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>

On Fri, 25 Oct 2024 13:11:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
>> 
>>> 1548: #endif /* ASSERT */
>>> 1549: 
>>> 1550:   push_cont_fastpath();
>> 
>> One of the callers of this gives a clue what it does.
>> 
>>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
>> 
>> Why do you do this here?  Oh please more comments...
>
> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245043

From dholmes at openjdk.org  Mon Oct 28 01:02:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:02:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
Message-ID: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>

On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I'm struggling to understand how a thread can already be on this list?
>>>
>> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.
>
> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776

From dholmes at openjdk.org  Mon Oct 28 01:16:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:16:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:

> 2380:   __ bind(after_transition);
> 2381: 
> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {

It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880

From rrich at openjdk.org  Mon Oct 28 07:59:07 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 07:59:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:

> 600: 
> 601:   address generate_cont_preempt_stub();
> 602:   address generate_cont_resume_monitor_operation();

The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

src/hotspot/share/runtime/synchronizer.cpp line 1559:

> 1557:         // and set the stack locker field in the monitor.
> 1558:         m->set_stack_locker(mark.locker());
> 1559:         m->set_anonymous_owner();  // second

Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818523530
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820

From alanb at openjdk.org  Mon Oct 28 09:21:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Oct 2024 09:21:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
 <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>
Message-ID: <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@github.com>

On Mon, 28 Oct 2024 00:26:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.
>
> Thanks for the explanation but that needs to be documented somewhere.

The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426

From yzheng at openjdk.org  Mon Oct 28 10:39:43 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 28 Oct 2024 10:39:43 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:

> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
> 328:                                                                                                                                      \
> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \

to make the type assert more precise:

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 20b9609cdbf..f2b8a69c03f 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -326,7 +326,7 @@
                                                                                                                                      \
   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
                                                                                                                                      \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
   volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
   volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
   volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
index 86d7277f88b..0492f28e15b 100644
--- a/src/hotspot/share/runtime/vmStructs.cpp
+++ b/src/hotspot/share/runtime/vmStructs.cpp
@@ -786,8 +786,8 @@
                                                                                                                                      \
   volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
   unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /* NOTE: no type */    \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
-  unchecked_nonstatic_field(ObjectMonitor,     _stack_locker,                                 BasicLock*)                            \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \
   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
   volatile_nonstatic_field(BasicLock,          _metadata,                                     uintptr_t)                             \
   nonstatic_field(ObjectMonitor,               _contentions,                                  int)                                   \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818818274

From coleenp at openjdk.org  Mon Oct 28 12:03:46 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 12:03:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
Message-ID: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>

On Mon, 28 Oct 2024 00:38:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.
>
> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818935916

From mullan at openjdk.org  Mon Oct 28 12:29:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 12:29:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Specify that params passed to getPermissions and implies are ignored and
   implies always returns false.
 - Change deprecated annotations to api notes on getPolicy and setPolicy.
 - clientlibs: Updated Problemlist
   Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
 - clientlibs: Deleted JPopupMenu tests
   The following tests are deleted as they don't hold value without SM
   test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
   always-on-top for apps which doesn't hold value after SM removal.
   
   test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
   Works differently on macOS and windows & linux but this is the expected behavior.
   Details in JDK-8342012. Not a functional issue.
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
   test renamed, test summary updated
 - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
 - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
 - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
 - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=03
  Stats: 65873 lines in 1867 files changed: 1158 ins; 61009 del; 3706 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From duke at openjdk.org  Mon Oct 28 13:07:28 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 28 Oct 2024 13:07:28 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
Message-ID: <t0d-HcCGxIowvbqe3CqLYAbMEOvKIE20m4RZL_McpWs=.1d4f7b09-05a1-4c34-81cc-6ba492f5405d@github.com>

On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

Looking at related bug history, https://bugs.openjdk.org/browse/JDK-8214078 was considered a Bug not an Enhancement. What is the distinction? Is it due to being supported on other architectures on the same OS versus being unsupported by OS?

Another question I had was: does this being an Enhancement affect backportability?

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2441532398

From rrich at openjdk.org  Mon Oct 28 13:10:44 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 13:10:44 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/share/runtime/objectMonitor.hpp line 202:

> 200: 
> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
> 202:   BasicLock* volatile _stack_locker;

IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029

From rrich at openjdk.org  Mon Oct 28 13:18:15 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 13:18:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
Message-ID: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>

On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/runtime/objectMonitor.hpp line 202:
> 
>> 200: 
>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>> 202:   BasicLock* volatile _stack_locker;
> 
> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

`ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819034645

From mullan at openjdk.org  Mon Oct 28 13:47:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 13:47:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
Message-ID: <t3eNL3sIsaBSuCKWvllA_vjpUyR7fH2u7cy2j_lCESE=.7a06982d-f836-4a2a-a711-418df3b180ae@github.com>

On Tue, 15 Oct 2024 22:09:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
>> 
>>> 665:      * @param codesource the codesource
>>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>>> 667:      * @return the permissions for the codesource
>> 
>> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?
>
> Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

I filed a follow-on issue to consider this: https://bugs.openjdk.org/browse/JDK-8343150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819084510

From mullan at openjdk.org  Mon Oct 28 14:03:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <vVe4o9wGohQAxFryEEG-ATg99g8s9Lud9YlM68S4BZc=.bcaa09df-a01d-4751-af7d-245fb008881c@github.com>

On Tue, 22 Oct 2024 20:20:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/FilePermission.java line 71:
> 
>> 69:  *
>> 70:  * @apiNote
>> 71:  * This permission cannot be used for controlling access to resources anymore
> 
> The word "anymore" is unnecessary.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819108633

From mullan at openjdk.org  Mon Oct 28 14:03:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
 <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
Message-ID: <0zzRwrMnjzNfCdMIUBA1pBgjiUjutknxWCyGtlODbto=.ad858095-07aa-41f9-a3f3-9f1059ac5b5c@github.com>

On Fri, 25 Oct 2024 13:44:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
>> 
>>> 38:  *
>>> 39:  * @apiNote
>>> 40:  * This permission cannot be used for controlling access to resources anymore
>> 
>> Unnecessary "anymore"
>
> Removed this word from all `Permission` subclasses; fix will be in next update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819109553

From mullan at openjdk.org  Mon Oct 28 14:03:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:05 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <MCGUYtIT23K7W16rxcBd1daw9mpMeqYpQ8Hki50NKaQ=.0f8f8488-24be-441e-9195-a9ddb63b3b69@github.com>

On Mon, 21 Oct 2024 22:57:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:
> 
>> 336: 
>> 337:     public static enum TestCase {
>> 338:         UNSECURE;
> 
> Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/e50cf64d771ed12de20e0a0500dc92f2e8a0abe4

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819096279

From mullan at openjdk.org  Mon Oct 28 14:03:06 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:06 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
 <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
Message-ID: <fTgvcpw5HqiI30y5Z2jb5QjrdO2A7ZB-xKxi-elxDoo=.f9a20ad6-15ca-45ba-8d0d-09eef26f2df8@github.com>

On Tue, 22 Oct 2024 20:55:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
>> 
>>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>>> 48:     }
>>> 49: 
>> 
>> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
>> 
>>> 115:             }
>>> 116:             popup.setVisible(false);
>>> 117:             frame.dispose();
>> 
>> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819100037
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819104451

From mullan at openjdk.org  Mon Oct 28 14:03:08 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:08 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
 <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
Message-ID: <0WKxUeUG7NcPFjIQDAKyMj2Q-zqjGzuDbgojtkuu-LA=.fbf49390-45aa-4238-84c7-ff8e18bdf74c@github.com>

On Tue, 22 Oct 2024 21:01:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I guess we can test this without SM since it tests SwingLazyValue?
>
> I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819105638

From mullan at openjdk.org  Mon Oct 28 14:08:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:08:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
 <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
Message-ID: <Fq8YAL6u5aQpBWsTKacnyqmH2to-keqqUMZlRfCMUU4=.4267c4b9-3527-463b-a5d4-8e582ccf0dd5@github.com>

On Wed, 23 Oct 2024 13:07:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
>> 
>>> 340:         throws Exception
>>> 341:     {
>>> 342:         action.run();
>> 
>> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?
>
> Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/82bb0d8207334d6072277e596fb16228f397fb77 and https://github.com/openjdk/jdk/pull/21498/commits/34439751f1b26e6ff1705e35f269e260401233af

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819119422

From mullan at openjdk.org  Mon Oct 28 14:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <ggccis0uu3BN3Kmofv1RlWFK8QykntW4i06p84FMTy8=.58430444-17a6-4a6e-b983-92588d6e21d5@github.com>

On Fri, 25 Oct 2024 20:34:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 489:
>> 
>>> 487: 
>>> 488:     /**
>>> 489:      * Adds a provider to the next position available..
>> 
>> Two periods at the end.
>
> Will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ed0f5c07f2bf3f3d7636533a77e8455d66bbf8b8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819146725

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>

On Thu, 24 Oct 2024 15:01:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1612:
> 
>> 1610:      * obtained.  The {@code String} value of this property is then
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * specification of {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819134820

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
Message-ID: <_-G-fWk2aAwcuoiLUlzkkNJ5ShuRx8dAOtOGfL1c9IE=.777bfd82-b0a6-43f3-a761-c9bcfe962553@github.com>

On Thu, 24 Oct 2024 19:33:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:
> 
>> 340:         /*
>> 341:          * There is no security manager, so disable access to RMI class
>> 342:          * loaders and use the would-de parent instead.
> 
> Fix typo "would-de" -> "would-be".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0f448e5fabac7941cd1b551aa1cc9ade773814ff

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819144885

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <GjxEiU7FQ9j_4EDb6nAwuApuvgHg6nlgwF-nGm0N5-w=.bf1d5c89-f5df-4a6c-aeed-50c382b5dd3c@github.com>

On Fri, 25 Oct 2024 20:48:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
>> 
>>> 30: 
>>> 31: /**
>>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
>> 
>> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.
>
> Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/275dabd4dbc8f443901dc5d82b281111dcbf15e6

>> src/java.base/share/classes/java/security/Policy.java line 374:
>> 
>>> 372:      *
>>> 373:      * @param codesource the CodeSource to which the returned
>>> 374:      *          PermissionCollection has been granted
>> 
>> Can we say this parameter is ignored? I see some other methods said so.
>> 
>> Same with the other `getPermissions` and `implies`.
>
> Yes, good suggestion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/4981da0fe50919e60cc036371f8bc8d7ee153849

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819165566
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819166630

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
Message-ID: <XMB2uyJSxzLDYmcYCxZ4_cGg3oS5gtRnksKaPr3GsBA=.8773b0cf-910b-4d29-b049-8ffea2cc4846@github.com>

On Fri, 25 Oct 2024 23:45:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.
>
> I see. Maybe this is enough.

Actually, I changed the message to "checking permissions is not supported" which is the same as the exception message of`Permission.checkGuard` and `AccessController.checkPermission`.

https://github.com/openjdk/jdk/pull/21498/commits/b6fe405dbbe8ec19a18174bc48dd649feca3d6aa

>> You mean move the first sentence of the deprecated text to here?
>
> Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819161320
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819162666

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <5cNNcS3nKl9Xq1oRJl6UR0Hsa7TScT14a1vA0YsNcO4=.515dbc77-19b3-425d-88d3-5752f3916eca@github.com>

On Fri, 25 Oct 2024 21:02:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Policy.java line 90:
>> 
>>> 88:  *       and subject to removal in a future release. Consequently, this class
>>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>>> 90:  *       the Security Manager or this class.
>> 
>> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.
>
> Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819163498

From mullan at openjdk.org  Mon Oct 28 14:26:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <s11CKR8J4p4OO6MhnvG9htT8gCepixeepGrWXpTkb6o=.56e88ee6-6436-4d6e-8056-a9e23d2d66de@github.com>

On Thu, 24 Oct 2024 15:04:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1780:
> 
>> 1778:      * <p>
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

> src/java.desktop/share/classes/java/beans/Expression.java line 1:
> 
>> 1: /*
> 
> Needs copyright year update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:
> 
>> 1: /*
> 
> Copyright year needs updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:
> 
>> 1: /*
> 
> Copyright years need updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819152998
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819155061
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156309
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156796

From mullan at openjdk.org  Mon Oct 28 14:51:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
Message-ID: <2jF7R61_yDPlFJ9Mh9c9RW-TDvtp4UPDj2OrU1--r4M=.9359f0c1-76e1-4287-8d53-05903baa6f25@github.com>

On Fri, 25 Oct 2024 23:58:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
>> 
>> Yes I think we can remove that text.
>> 
>>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
>> 
>> You mean a warning like we have in the `Permission` subclasses?
>> 
>> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.
>
> Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.
> 
> On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

I removed the text "permissions which are retrieved by the system policy by default" from the class description and added an API note that permissions cannot be used to control access to resources. See https://github.com/openjdk/jdk/pull/21498/commits/8b527c90e434e63fd00a719aedda50d8d27e93b5

> On the other hand, I looked at its subclasses and their getPermissions(CodeSource cs) could return quite 
> complicated permission collections. I assume it does not really matter since they are all useless now, right?

Yes, although I would prefer to handle those as follow-on issues, I filed one for `URLClassLoader`: https://bugs.openjdk.org/browse/JDK-8343150

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819210679

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <ecXA9z7pXC8iHPzwyo5ZNBiptYS950MNZdm3yjHFd-Y=.f95ed696-c762-40f2-9079-e218b36f164b@github.com>

On Thu, 24 Oct 2024 15:57:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:
> 
>> 69:      *
>> 70:      * @param targetType   the class object of the type to be edited
>> 71:      * @param editorClass  the class object of the editor classs
> 
> Suggestion:
> 
>      * @param editorClass  the class object of the editor class
> 
> Typo with an extra ?s?. The line should remain unchanged.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

> src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:
> 
>> 1: /*
> 
> Needs updating the copyright year.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819200392
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819172129

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
 <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
Message-ID: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>

On Fri, 25 Oct 2024 23:20:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
>> I can update the test summary accordingly  -
>>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
>> 
>> @azuev-java Your thoughts?
>
> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819186623

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
Message-ID: <IaFWniwJ0ayT2cKcMKQ3OSQfgSbE6Cdm_vACx8gYhNQ=.6ac87108-0c02-4e7f-a85c-b1c140e78512@github.com>

On Fri, 25 Oct 2024 20:31:40 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
>> 
>>> 1: /*
>> 
>> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
>> 
>> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
>> 
>> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.
>
> This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085
> 
> Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819190841

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
 <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
Message-ID: <3UWYFypKVUDbFKF8O3Q1XuygK6WoWNs50jtx7yQooR4=.c7f4127d-2927-4750-8983-be5b7d163883@github.com>

On Fri, 25 Oct 2024 18:52:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
>> 
>>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?
>
> The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:
> 
> https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902
> 
> On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.
> 
> At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.
> 
> I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.
> 
> Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.
> 
> Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819180850

From mullan at openjdk.org  Mon Oct 28 15:09:54 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 15:09:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <di3QwjPshatki7F1k9zaiWfs8C5lgRBvLiYnMGXdmYE=.b95d7132-856f-4fbf-a7b1-818ed02d144d@github.com>

On Fri, 25 Oct 2024 20:59:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:
> 
>> 123:     }
>> 124: 
>> 125:     @Benchmark
> 
> Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

`ProtectionDomain` has not been deprecated and classes are still populated with PDs w/o an SM, so it may still have some value for measuring performance and detecting regressions/improvements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819242889

From coleenp at openjdk.org  Mon Oct 28 16:27:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 16:27:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <L4tCHCM7YVRAbG1ApiIzIRZcKWuqiX821nIB9Grdls0=.8c8d62e3-4112-414d-9d5b-2a457bc367f5@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

Noticed while downloading this that some copyrights need updating.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307

From coleenp at openjdk.org  Mon Oct 28 16:41:32 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 16:41:32 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
Message-ID: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>

On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
> 
>> 117:   return  mask.num_oops()
>> 118:         + 1 // for the mirror oop
>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
> 
> Where is this temp oop slot set and used?

It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819394224

From alanb at openjdk.org  Mon Oct 28 16:45:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Oct 2024 16:45:27 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
Message-ID: <CYgbHumMCId3co1jKwVBmY7UqNQ7hoOL3cbs-X9LYWU=.dd17e1aa-b30c-441c-9233-950bc4b9e588@github.com>

On Fri, 25 Oct 2024 16:58:42 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
>> 
>> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
>> 
>> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
>> 
>> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add bug ID to test
>  - Update jtreg SecureDS test to use `@requires` instead of `instanceof` logic

I think this looks okay.

It changes the Linux port from using futimesat to futimes. This should be okay as futimes has been available for a long time.

Change the macOS to not use dlsym is okay too, it had to use dlsym in the original port.

The update to the test looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21696#pullrequestreview-2399631689

From alanb at openjdk.org  Mon Oct 28 16:45:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Oct 2024 16:45:27 GMT
Subject: RFR: 8343020: (fs) Add support for SecureDirectoryStream on macOS
 [v3]
In-Reply-To: <t0d-HcCGxIowvbqe3CqLYAbMEOvKIE20m4RZL_McpWs=.1d4f7b09-05a1-4c34-81cc-6ba492f5405d@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
 <4CqOLItolIdxGe6yuqPhDU4AJZgguSxOXgViS8eBp2k=.c767f2e7-6256-428d-b3f0-6dd22a6fe1de@github.com>
 <t0d-HcCGxIowvbqe3CqLYAbMEOvKIE20m4RZL_McpWs=.1d4f7b09-05a1-4c34-81cc-6ba492f5405d@github.com>
Message-ID: <3uA9lAeFavCBoyviNOcZDwhiR7lgeNel7UBZYfm0P34=.b46ae59a-4605-45ba-83ee-2c68393f4070@github.com>

On Mon, 28 Oct 2024 13:03:46 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Looking at related bug history, https://bugs.openjdk.org/browse/JDK-8214078 was considered a Bug not an Enhancement. What is the distinction? Is it due to being supported on other architectures on the same OS versus being unsupported by OS?
> 
> Another question I had was: does this being an Enhancement affect backportability?

SecureDirectoryStream is optional and this JBS issue is add support on macOS. So I think Enhancement is the right issue type. I don't think we can classify as a bug, it's just that this feature couldn't be implemented on macOS when the original port was done in 7u4.

I'm not involved in update releases.

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

PR Comment: https://git.openjdk.org/jdk/pull/21696#issuecomment-2442102468

From duke at openjdk.org  Mon Oct 28 17:01:46 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 28 Oct 2024 17:01:46 GMT
Subject: Integrated: 8343020: (fs) Add support for SecureDirectoryStream on
 macOS
In-Reply-To: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
References: <RgBlS6BMo3ylel_ZGfa9lKx0r50GJ6SkXlPlqbW53Xo=.86ae1a81-b2e2-4e80-a46a-b67a606669b3@github.com>
Message-ID: <hhhVGeL-ByhNDmBkjlGpf8YW4u9WY4Kvk2U1lz--7MI=.ae4fa49b-3bf6-4580-b9d7-53d53485f428@github.com>

On Thu, 24 Oct 2024 21:54:55 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> OpenJDK will not produce SecureDirectoryStreams on MacOS. Support for SecureDirectoryStream on UNIX-like OSes is predicated on the `SUPPORTS_OPENAT` flag in UnixNativeDispatcher. That flag in turn is set when the runtime environment supports `openat`, `fstatat`, `unlinkat`, `renameat`, `futimesat`, and `fdopendir`.
> 
> This fails on MacOS because `futimesat` does not exist on that platform, apparently having been a proposed-but-not-accepted part of POSIX some time ago. While there is an indirect replacement that is supported on MacOS - `utimensat` - this is not actually needed, because the unique functionality provided by `futimesat` (that is, performing the action of `futimes` relative to an open directory file descriptor) is not utilized, since the only place this function is used passes `NULL` as the relative filename argument.
> 
> Replacing this with simply calling `futimes` instead allows `SecureDirectoryStream` to function on MacOS.
> 
> Additionally, we must ensure that `openat`, `fstatat`, and `fdopendir` are properly detected on MacOS x64, because there are 32- and 64-bit variations on that platform which misbehave subtly when done improperly.

This pull request has now been integrated.

Changeset: 9f6d5b46
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f6d5b46ce2cfcdb39f94b8ac8621ee21f4e8740
Stats:     25 lines in 3 files changed: 3 ins; 6 del; 16 mod

8343020: (fs) Add support for SecureDirectoryStream on macOS

Reviewed-by: bpb, alanb

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

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

From pchilanomate at openjdk.org  Mon Oct 28 17:24:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:24:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v13]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <dXalEie51SeOozW8Hjna9HrvB33PjXM_JxkPAcKAwOE=.89945004-4fa6-4420-baf4-e38ae1c6a9dd@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Simplify set last_sp in prepare_freeze_interpreted_top_frame
 - add authenticate_return_address() in StubAssembler::epilogue
 - Make member functions in ObjectWaiter const
 - Rename inflating_thread to locking_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/66d5385f..7cb4cffd

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

  Stats: 52 lines in 15 files changed: 1 ins; 3 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Mon Oct 28 17:35:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
Message-ID: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>

On Sat, 26 Oct 2024 00:17:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>
Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:
> 
>> 189:   // must restore the rfp value saved on enter though.
>> 190:   if (use_pop) {
>> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));
> 
> leave() also calls authenticate_return_address(), which I assume we still want to call here.
> How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

Right. I added it here for now to follow the same style in all platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Suggestion:
> 
>   f.interpreter_frame_set_last_sp(f.unextended_sp());

Changed, here and in the other platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
> 
>> 157: 
>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
> 
> Suggestion:
> 
>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
> 
> Isn't that 2 words, not 3?

The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
I don't know why we do that for 64 bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819473410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819465574
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086

From pchilanomate at openjdk.org  Mon Oct 28 17:35:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
 <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
Message-ID: <IIT6ZK5VHBwBQs0KkppCGOwgf55SIZk7-HKtZvFfIRQ=.d60d57ef-dd07-4a13-8909-969ad7a53d6b@github.com>

On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:
>> 
>>> 186:   // Avoid using a leave instruction when this frame may
>>> 187:   // have been frozen, since the current value of rfp
>>> 188:   // restored from the stub would be invalid. We still
>> 
>> It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>> Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
>>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>>
> Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
I think we need it for the pending exception case. I see we use rfp to get the exception pc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263

From pchilanomate at openjdk.org  Mon Oct 28 17:35:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
Message-ID: <RwO07ZXmUK-ZXOELiDyi595hIZZECD2720ZsYwLPGQE=.30718afc-d202-45ee-8ab3-9d9ae5e0959a@github.com>

On Fri, 25 Oct 2024 21:57:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 268:
> 
>> 266:   }
>> 267: 
>> 268:   int num_oops() { return _num_oops; }
> 
> I can't find what uses this from OopMapCacheEntry.

It's needed for verification in VerifyStackChunkFrameClosure. It's called in OopMapCacheEntry::fill_for_native(), and we get there from here: https://github.com/openjdk/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp#L114

> src/hotspot/share/runtime/objectMonitor.hpp line 71:
> 
>> 69:   bool is_wait()           { return _is_wait; }
>> 70:   bool notified()          { return _notified; }
>> 71:   bool at_reenter()        { return _at_reenter; }
> 
> should these be const member functions?

Yes, changed to const.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958

From pchilanomate at openjdk.org  Mon Oct 28 17:35:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v13]
In-Reply-To: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
Message-ID: <az8AjVGzJn_UTq7msHjpPM0jnyOISv5jEHsxcfKAUjI=.a74363e6-08d2-4364-b1ce-b274b82f23de@github.com>

On Fri, 25 Oct 2024 22:22:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Simplify set last_sp in prepare_freeze_interpreted_top_frame
>>  - add authenticate_return_address() in StubAssembler::epilogue
>>  - Make member functions in ObjectWaiter const
>>  - Rename inflating_thread to locking_thread
>
> src/hotspot/share/runtime/objectMonitor.hpp line 43:
> 
>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 43: // See next_waiter(), first_waiter(), etc.
> 
> Also a nice cleanup.  Did you reconcile the JVMTI code?

We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651

From pchilanomate at openjdk.org  Mon Oct 28 17:35:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
 <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>
Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.58bb9152-274c-4c43-9bca-2feae81bf4c6@github.com>

On Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.
>
> ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

Changed to locking_thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819461999

From pchilanomate at openjdk.org  Mon Oct 28 17:40:31 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:40:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>
Message-ID: <V-i82-l9tdu_WL8c3eYDdX7LZxIpsl57b-90LWjeYyU=.3e835056-4a2d-4532-abb5-92b1d3ec79d2@github.com>

On Sat, 26 Oct 2024 00:30:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:
> 
>> 336:   // Make sure that extended_sp is kept relativized.
>> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
>> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()
> 
> Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

There are two cases where the interpreter native wrapper frame is freezed: synchronized native method, and `Object.wait()`. The extra push of the parameters to the stack is done after we synchronize on the method, so it only applies to `Object.wait()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705

From honkar at openjdk.org  Mon Oct 28 18:14:53 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <UibYchrEh4IMGTL2M1YjvpMysipL1Clnov5XIuBs9zg=.d2006057-0749-4a3e-b194-3a3d512d0e5e@github.com>

On Fri, 25 Oct 2024 18:09:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

@aivanov-jdk Clientlibs review comments have been addressed and updated. Please re-review when you get a chance.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442286841

From honkar at openjdk.org  Mon Oct 28 18:14:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
Message-ID: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>

On Fri, 25 Oct 2024 22:52:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).
>
> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
> But I don't see a problem with keeping the rest of the test.

Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819521798

From bchristi at openjdk.org  Mon Oct 28 18:28:01 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:01 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <yPy9DNlPYRyWTHBE5WWerf-MwhvFPW0tXLeaEQ-ZB8s=.bf67126c-a0fd-436e-ac50-60ba35dd8923@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

java.prefs changes look good. (No prefs tests were changed.)

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2397377427

From bchristi at openjdk.org  Mon Oct 28 18:28:04 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:

> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link

Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817954250

From ihse at openjdk.org  Mon Oct 28 18:28:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Oct 2024 18:28:37 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86
 Port
Message-ID: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>

This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).

This is the summary of JEP 479:
> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

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

Commit messages:
 - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339783
  Stats: 1551 lines in 53 files changed: 70 ins; 1417 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From ihse at openjdk.org  Mon Oct 28 18:28:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Oct 2024 18:28:44 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

For this patch, I have removed the parts of the build that I knew of that were related to 32-bit Windows. Furthermore, I have searched for all defines across the code base that are related to 32-bit Windows, and removed the parts of the code that is no longer relevant. I have also made a cross-codebase search for terms like "win" and "32" and glanced through the results (that was a huge list) to see if I could spot anything that might need attention. 

There might of course still be special code that was developed to take care of Windows 32-bit that is no longer needed, but that is hard to find automatically. If anyone knows about some particular code, please let me know!

Most of the code was trivial to handle, but there are a few instances where I'd like some input from code owners. I've marked these with `FIXME` in the patch.

src/hotspot/cpu/x86/interpreterRT_x86_32.cpp line 47:

> 45: #ifdef AMD64
> 46: #ifdef _WIN64
> 47:    // FIXME: This is weird. How can we ever have _WIN64 for 32-bit code? I wonder what was meant. /ihse

I think this piece of code will never get compiled and should be removed, and just the `#else` clause kept, but I guess some code archaeology is in place to figure out how and why this was added in the first place.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1478:

> 1476:   int frame_complete = ((intptr_t)__ pc()) - start;
> 1477: 
> 1478:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

This file is now Linux only, so we should be able to remove any Windows special code. Someone with better knowledge about the product needs to confirm that the comment is indeed correct, and that this was only needed on Windows.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1714:

> 1712:   __ restore_cpu_control_state_after_jni(noreg);
> 1713: 
> 1714:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

Same here as above.

src/hotspot/cpu/x86/x86_32.ad line 3715:

> 3713: %}
> 3714: 
> 3715: // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

Here too we don't need Windows-specific support, since this is Linux only. But I need confirmation that the comment is correct so this code is really just Windows-specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2442297077
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819532224
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819533829
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819533988
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819535092

From prr at openjdk.org  Mon Oct 28 18:44:19 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Oct 2024 18:44:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <22AJ3u3UiSxFqANDpVqeJV3-H54pfkjt4YfbhbQ_T2Q=.8228b822-dd85-436d-a208-ff15995098eb@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The client/desktop related src and test changes have all now been reviewed by at least one client/desktop engineer.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399915245

From dlong at openjdk.org  Mon Oct 28 18:54:43 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 18:54:43 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>

On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
>> 
>>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>>> 1554:   adr(rscratch1, resume_pc);
>>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
>> 
>> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.
>
> Its indeed difficult to see how the value is propagaged. I think it goes like this:
> 
> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

Thanks, that's what I was missing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819586705

From pchilanomate at openjdk.org  Mon Oct 28 19:02:42 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:42 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v14]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <NKHa1oLTI0rADOD0YbcU2stZ315uyCkZnJyJ3LMp3rI=.7817f6e5-6abb-4c74-b1be-54dbdc42811e@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  extra suggestion to prepare_freeze_interpreted_top_frame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/7cb4cffd..bd918fa7

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

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

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

From pchilanomate at openjdk.org  Mon Oct 28 19:02:44 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:44 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
Message-ID: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>

On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long <dlong at openjdk.org> wrote:

> > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.
> 
> During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.
>
The problem is that freezing the frames can fail. By then we would have already added the ObjectWaiter as representing a virtual thread. Regarding efficiency (and ignoring the previous issue) both approaches would be equal anyways, since regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:
> 
>> 131: 
>> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 
> Suggestion:
> 
>   assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

Changed, here and in the other platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
Message-ID: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>

On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
>> 
>>> 308:     sp -= 2;
>>> 309:     sp[-2] = sp[0];
>>> 310:     sp[-1] = sp[1];
>> 
>> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?
>
> Could the problem be solved with a resume adapter instead, like the interpreter uses?

The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
Message-ID: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>

On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
It will just move the task of adjusting the size of the frame somewhere else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819594475

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>
Message-ID: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.46af32e2-e5db-4220-adae-d3bf80a76a8f@github.com>

On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Its indeed difficult to see how the value is propagaged. I think it goes like this:
>> 
>> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
>> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
>> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
>> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771
>
> Thanks, that's what I was missing.

Right, whatever address is in last_Java_pc is the one we are going to freeze for that frame, i.e. that's the address we are going to return to when resuming. For the freeze slow path this was already how it worked before this PR. For the fast path I added a case to correct the last pc that we freeze on preemption, as Richard pointed out in the last link, since otherwise we would freeze a different one. The idea is that if we already freeze the right pc, then on thaw we don't have to do anything. Note that when there are interpreter frames on the stack we always take the slow path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819595482

From bchristi at openjdk.org  Mon Oct 28 19:05:46 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:05:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <MVzDG3v00pr-BbVREYbr2PXIfV-ChDESYKHwRqlWVTQ=.9fc15703-9e3a-439d-aa88-f8b06f71fac2@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 400:

> 398:      * AccessControlContext and contextClassLoader of new threads to
> 399:      * be the same as the thread invoking this
> 400:      * {@code privilegedThreadFactory} method.  A new

We no longer state that the contextClassLoader is set, though `PrivilegedThreadFactory` _does_ still set the ccl. Is this OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819601556

From dlong at openjdk.org  Mon Oct 28 19:07:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 19:07:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>
Message-ID: <MLUFZMaiWbNcdv_VRsyXdS0Xe7gKx4zK1YvVDXEiCUM=.f72c2828-d1d9-4ee3-afec-0156b7576f7a@github.com>

On Sat, 26 Oct 2024 06:56:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>> 
>>> 1565: 
>>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>>> 1567:   bind(resume_pc);
>> 
>> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?
>
> The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.
> 
> At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

OK, that makes sense now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366

From bchristi at openjdk.org  Mon Oct 28 19:19:52 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:19:52 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 529:

> 527:      * execute the given {@code callable} under the current access
> 528:      * control context, with the current context class loader as the
> 529:      * context class loader. This method should normally be invoked

We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819618471

From shade at openjdk.org  Mon Oct 28 19:37:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 19:37:23 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Cursory review, sometimes with my 32-bit x86 maintainer hat on :)

make/autoconf/platform.m4 line 669:

> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
> 669:   if test "x$OPENJDK_TARGET_OS" = xwindows && test "x$OPENJDK_TARGET_CPU" = xx86; then

Can you just hollow `PLATFORM_CHECK_DEPRECATION` out, without removing? I think I am going to use it for full 32-bit port deprecation.

make/modules/jdk.accessibility/Launcher.gmk line 56:

> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
> 55:       NAME := jaccessinspector, \
> 56:       EXTRA_SRC := \

I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?

Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.

src/hotspot/os/windows/os_windows.cpp line 136:

> 134:   #define __CPU__ amd64
> 135: #else
> 136:   #define __CPU__ unknown

Should this be just `#error Unknown CPU`?

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:

> 521: 
> 522: extern "C" int SpinPause () {
> 523: #ifdef AMD64

Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2399951993
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819593526
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819596530
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819620086
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819631224

From shade at openjdk.org  Mon Oct 28 19:37:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 19:37:24 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>
Message-ID: <_3lAZxejWWmQabtHhqCrOePqNu5-fR07EuLvQuGHEDc=.7b429041-4b97-41f6-afb6-c60b477748c5@github.com>

On Mon, 28 Oct 2024 18:15:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/cpu/x86/interpreterRT_x86_32.cpp line 47:
> 
>> 45: #ifdef AMD64
>> 46: #ifdef _WIN64
>> 47:    // FIXME: This is weird. How can we ever have _WIN64 for 32-bit code? I wonder what was meant. /ihse
> 
> I think this piece of code will never get compiled and should be removed, and just the `#else` clause kept, but I guess some code archaeology is in place to figure out how and why this was added in the first place.

I think this is a copy-paste error from [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809): the code from `interpreterRT_x86_64.cpp` (where `WIN64` makes sense) was copy-pasted here in `interpreterRT_x86_32.cpp`. In fact, `AMD64` in  `interpreterRT_x86_64.cpp` makes no sense as well. I'll clean it up: [JDK-8343167](https://bugs.openjdk.org/browse/JDK-8343167).

> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1478:
> 
>> 1476:   int frame_complete = ((intptr_t)__ pc()) - start;
>> 1477: 
>> 1478:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> This file is now Linux only, so we should be able to remove any Windows special code. Someone with better knowledge about the product needs to confirm that the comment is indeed correct, and that this was only needed on Windows.

Nah, leave it as is. Let's not regress native stubs unnecessarily, and this whole file would be gone after we deprecate 32-bit port completely.

> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1714:
> 
>> 1712:   __ restore_cpu_control_state_after_jni(noreg);
>> 1713: 
>> 1714:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> Same here as above.

Same reply as above :)

> src/hotspot/cpu/x86/x86_32.ad line 3715:
> 
>> 3713: %}
>> 3714: 
>> 3715: // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> Here too we don't need Windows-specific support, since this is Linux only. But I need confirmation that the comment is correct so this code is really just Windows-specific.

It looks like it is a dusty corner case. But the same logic as above applies: let's not touch it, and instead wait for it to go away with the remaining bits of 32-bit x86 port. I see `eRegP_no_EBP` is used for safepoint polls, so if we are wrong about the scope of this, rewriting these match rules to just `eRegP` might introduce surprising regressions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819606745
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819611536
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819612008
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819617067

From dlong at openjdk.org  Mon Oct 28 19:49:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 19:49:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
Message-ID: <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>

On Sat, 26 Oct 2024 07:04:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
>> 
>>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>>> 3795:   __ testbool(rscratch1);
>>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
>> 
>> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?
>
> The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858

From dlong at openjdk.org  Mon Oct 28 20:12:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 20:12:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
Message-ID: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>

On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
>> 
>>> 117:   return  mask.num_oops()
>>> 118:         + 1 // for the mirror oop
>>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
>> 
>> Where is this temp oop slot set and used?
>
> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819687576

From rriggs at openjdk.org  Mon Oct 28 20:14:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Oct 2024 20:14:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed all tests under test/jaxp/javax/xml/jaxp.
A few imports moved around unnecessarily but otherwise looks fine.

test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java line 53:

> 51: import org.w3c.dom.Node;
> 52: import org.w3c.dom.NodeList;
> 53: import static jaxp.library.JAXPTestUtilities.USER_DIR;

The import change was unnecessary.

test/jaxp/javax/xml/jaxp/unittest/sax/Bug7057778Test.java line 48:

> 46: import org.xml.sax.XMLReader;
> 47: import org.xml.sax.ext.DefaultHandler2;
> 48: import static jaxp.library.JAXPTestUtilities.USER_DIR;

Keep imports JAXPTestUtilities imports together.

test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/EventReaderTest.java line 32:

> 30: import javax.xml.stream.XMLStreamException;
> 31: import javax.xml.stream.events.StartDocument;
> 32: import static org.testng.Assert.assertEquals;

Import change is unnecessary.

test/jaxp/javax/xml/jaxp/unittest/validation/Bug6925531Test.java line 52:

> 50:             + "        targetNamespace='jaxp13_test'\n"
> 51:             + "        elementFormDefault='qualified'>\n"
> 52:             + "    <element name='test' type='string'/>\n"

Would be a good use for multi-line strings.   """ """
But not worth changing.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathPrecedingTest.java line 2:

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

no change necessary

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399985101
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819611468
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819667734
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819672433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819646448
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819624631

From dlong at openjdk.org  Mon Oct 28 20:31:31 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 20:31:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
 <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
Message-ID: <ZiD3zPbaBP37iLtLrDy4bnb1cWW_M0jjnDzdbQt_ccE=.6fc41f86-2cfe-4701-ad89-4346e6853793@github.com>

On Mon, 28 Oct 2024 17:30:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
>> 
>>> 157: 
>>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
>> 
>> Suggestion:
>> 
>>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
>> 
>> Isn't that 2 words, not 3?
>
> The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
> I don't know why we do that for 64 bits.

OK, I think there are historical or technical reasons why it's hard to change, because of the way the JVM spec is written.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281

From pchilanomate at openjdk.org  Mon Oct 28 20:58:33 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix vmStructs definitions
 - Remove generate_cont_resume_monitor_operation() + comment in ObjectSynchronizer::inflate_impl()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/bd918fa7..fc9aa074

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

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

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

From pchilanomate at openjdk.org  Mon Oct 28 20:58:33 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>

On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
> 
>> 2380:   __ bind(after_transition);
>> 2381: 
>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
> 
> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819744051

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>
Message-ID: <Wz421HivVaSYw32P_FziXYHdelelv3igEJaecq1D0qM=.f4aa5a06-0330-4a13-8d1a-663aec849281@github.com>

On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:
> 
>> 600: 
>> 601:   address generate_cont_preempt_stub();
>> 602:   address generate_cont_resume_monitor_operation();
> 
> The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

Removed.

> src/hotspot/share/runtime/synchronizer.cpp line 1559:
> 
>> 1557:         // and set the stack locker field in the monitor.
>> 1558:         m->set_stack_locker(mark.locker());
>> 1559:         m->set_anonymous_owner();  // second
> 
> Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

No, I removed that comment. Both will be visible once we publish the monitor with `object->release_set_mark(markWord::encode(m))`. There was a "first" comment in method ObjectMonitor::set_owner_from_BasicLock() which I removed in [1]. Clearing _stack_locker now happens here in the `mark.has_monitor()` case. The order there doesn't matter either. If some other thread sees that the owner is anonymous and tries to check if he is the owner the comparison will always fail, regardless of reading the BasicLock* value or a nullptr value.

[1] https://github.com/pchilano/jdk/commit/13353fdd6ad3c509b82b1fb0b9a3d05284b592b7#diff-4707eeadeff2ce30c09c4ce8c5a987abf58ac06f7bf78e7717cffa9c36cc392fL195

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746524
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746309

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>
Message-ID: <K5riEGYhTK3b9yrDmiB_hU9eUxZ5SstOxTPMSq0_VOw=.f58a72c2-ca12-428b-b05b-ebacb2123c12@github.com>

On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:
> 
>> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>> 328:                                                                                                                                      \
>> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> 
> to make the type assert more precise:
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 20b9609cdbf..f2b8a69c03f 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -326,7 +326,7 @@
>                                                                                                                                       \
>    nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>                                                                                                                                       \
> -  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> +  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
>    volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
>    volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
>    volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
> diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
> index 86d7277f88b..0492f28e15b 100644
> --- a/src/hotspot/share/runtime/vmStructs.cpp
> +++ b/src/hotspot/share/runtime/vmStructs.cpp
> @@ -786,8 +786,8 @@
>                                                                                                                                       \
>    volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
>    unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /*...

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746890

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
 <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>
Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.d58b3e5a-0959-4cf1-a27c-59c2111012eb@github.com>

On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 202:
>> 
>>> 200: 
>>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>>> 202:   BasicLock* volatile _stack_locker;
>> 
>> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
>> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?
>
> `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

I remember I thought about doing this but discarded it. I don't think it will reduce complexity since we still need to handle that as a special case. In fact I removed several checks throughout the ObjectMonitor code where we had to check for this case. Now it works like with LM_LIGHTWEIGHT (also a plus), where once the owner gets into ObjectMonitor the owner will be already fixed. So setting and clearing _stack_locker is contained here in ObjectSynchronizer::inflate_impl(). Granted that we could do the same when restricting the ids, but then complexity would be the same. Also even though there are no guarantees about the ids I think it might look weird for somebody looking at a thread dump to only see odd ids.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819748043

From pchilanomate at openjdk.org  Mon Oct 28 21:04:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 21:04:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
Message-ID: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>

On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.
>
> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819757374

From mullan at openjdk.org  Mon Oct 28 21:07:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 21:07:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:

> 1: /*

@wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:

> 1: /*

Missed a copyright update; will fix.

test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:

> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
> 29:  * @compile -XDignore.symbol.file Marshal.java
> 30:  * @run main/othervm/java.security.policy==test.policy Marshal

With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.

Also, missing a copyright update, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819757618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819758300
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819756247

From dlong at openjdk.org  Mon Oct 28 21:10:19 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 21:10:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:

> 144:   // Make sure that locals is already relativized.
> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)

What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504

From pchilanomate at openjdk.org  Mon Oct 28 21:16:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 21:16:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
 <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
Message-ID: <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>

On Mon, 28 Oct 2024 19:45:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> If preemption was cancelled, we skip over the cleanup.
>
We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854

From bpb at openjdk.org  Mon Oct 28 21:33:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Oct 2024 21:33:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <3zWmdX5pdYRfq9hBJGyY-lDdhgs9xuZ2xPLLKgpPYzU=.81747961-8d9b-4488-b31e-37d6a5bf4003@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The `java/nio/file` src and test changes look all right.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442669945

From bchristi at openjdk.org  Mon Oct 28 22:10:15 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 22:10:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <HOiCwZKc-UJsz_0__Bzto-LuAGch7-AOdKyEs0xT_3Q=.248b7897-841e-4ad5-8f89-10a3e7cf8177@github.com>

On Fri, 25 Oct 2024 20:13:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:
> 
>> 26:  * @bug 6552961 6558429
>> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
>> 28:  * @run main PrivilegedCallables
> 
> There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

`Executors.privilegedCallable()` and `Executors.privilegedCallableUsingCurrentClassLoader()` are still present in the `Executors` class (though deprecated for removal). This test should be removed when those methods are removed. In the meantime, the name of the test seems reasonable to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819824791

From dlong at openjdk.org  Mon Oct 28 22:10:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 22:10:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>
Message-ID: <ETmP3VrD8GXkLs_ttoK9aNgV3fODhmMzcRFzgwooApI=.0b1a54fb-88e4-441f-a2b2-49bfa6b5fcb3@github.com>

On Mon, 28 Oct 2024 20:58:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix vmStructs definitions
>  - Remove generate_cont_resume_monitor_operation() + comment in ObjectSynchronizer::inflate_impl()

Looking at this reminds me of a paper I read a long time ago, "Using continuations to implement thread management and communication in operating systems" (https://dl.acm.org/doi/10.1145/121133.121155).

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996

From pchilanomate at openjdk.org  Mon Oct 28 22:10:54 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>

On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.
>
> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819831895

From pchilanomate at openjdk.org  Mon Oct 28 22:10:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
Message-ID: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>

On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.
>
> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:

|                ThreadA                |                   ThreadB             |           ThreadC             |
| --------------------------------------| --------------------------------------| ---------------------------------------------|
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
|                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
|                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
|                                       | ExitEpilog:releases monitorB          |                                              |
|                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
|                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
|                                       |                                       |     continues execution in Java              |
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
|                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
|  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
|  ExitEpilog:releases monitorA         |                                       |                                              |
|  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472

From pchilanomate at openjdk.org  Mon Oct 28 22:10:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>
Message-ID: <Y29qP6KBB5ziQIMQAKW8UDf4E0oolb63AtBAJtMrlPc=.d02c4f14-1d4f-45e0-9b75-8dbfd211e950@github.com>

On Mon, 28 Oct 2024 00:31:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is, we still increment _waiters for the vthread case.
>
> Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

If the ObjectWaiter is associated with a vthread(we unmounted in `Object.wait`) we just return null. We'll skip it from JVMTI code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478

From coleenp at openjdk.org  Mon Oct 28 22:57:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
 <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>
Message-ID: <Iauve4e-TfFi91-Hv_DrqLHSnKCNs5bspnsFy8b737w=.9f1bb78f-0f6d-49d9-862d-bf342756896b@github.com>

On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???
>
> Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

Yes the comment did seem to contradict the name of the function.  But it's something we can re-examine at some later time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819858784

From coleenp at openjdk.org  Mon Oct 28 22:57:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
Message-ID: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>

On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?
>
> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819869538

From dlong at openjdk.org  Mon Oct 28 22:57:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 22:57:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
 <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
 <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>
Message-ID: <kIzpbt39CsWh1gBz35CCjVl8f7vkM_2dZp84RE0OC_U=.2571c54c-2bbf-47c5-aa87-c317d0fd6cb7@github.com>

On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.
>
>> If preemption was cancelled, we skip over the cleanup.
>>
> We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

OK got it.  I guess it's too early to know if it's worth it to further optimize this case, which is hopefully rare.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819865539

From coleenp at openjdk.org  Mon Oct 28 22:57:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.f19ed659-0b21-4fef-953c-cb87d007709c@github.com>

On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
>> 
>>> 1273: 
>>> 1274:   if (caller.is_interpreted_frame()) {
>>> 1275:     _total_align_size += frame::align_wiggle;
>> 
>> Please put a comment here about frame align-wiggle.
>
> I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

ok that's helpful.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:
>> 
>>> 1550:   assert(!cont.is_empty(), "");
>>> 1551:   // This is done for the sake of the enterSpecial frame
>>> 1552:   StackWatermarkSet::after_unwind(thread);
>> 
>> Is there a new place for this StackWatermark code?
>
> I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

Okay, good!

>> src/hotspot/share/runtime/objectMonitor.hpp line 43:
>> 
>>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>>> 43: // See next_waiter(), first_waiter(), etc.
>> 
>> Also a nice cleanup.  Did you reconcile the JVMTI code?
>
> We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

Ok, good that there isn't a jvmti special case here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860241
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860643
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819864520

From dlong at openjdk.org  Mon Oct 28 23:13:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:13:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
Message-ID: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>

On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>> 
>>> 2380:   __ bind(after_transition);
>>> 2381: 
>>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>> 
>> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?
>
> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.

I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819880228

From erikj at openjdk.org  Mon Oct 28 23:21:06 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Oct 2024 23:21:06 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

I looked at the build system parts.

make/modules/jdk.accessibility/Lib.gmk line 34:

> 32: 
> 33:   ##############################################################################
> 34:   ## Build libjavaaccessbridge

Is double `##` intentional?

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2400419486
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819883994

From erikj at openjdk.org  Mon Oct 28 23:21:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Oct 2024 23:21:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>

On Mon, 28 Oct 2024 18:58:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> make/modules/jdk.accessibility/Launcher.gmk line 56:
> 
>> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>> 55:       NAME := jaccessinspector, \
>> 56:       EXTRA_SRC := \
> 
> I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?
> 
> Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.

I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819883595

From dlong at openjdk.org  Mon Oct 28 23:24:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:24:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
Message-ID: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>

On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.
>
> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819887000

From dlong at openjdk.org  Mon Oct 28 23:41:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:41:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
Message-ID: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>

On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.
>
>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>
> It will just move the task of adjusting the size of the frame somewhere else.

> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.

If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819896849

From dlong at openjdk.org  Mon Oct 28 23:49:25 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:49:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>

On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption?  It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards?  We aren't doing the monitor check atomically, so the monitor could get released right after we check it.  So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740

From pchilanomate at openjdk.org  Tue Oct 29 00:04:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment in VThreadWaitReenter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/fc9aa074..056d21ec

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

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

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

From pchilanomate at openjdk.org  Tue Oct 29 00:04:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
Message-ID: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>

On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.
>
> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>
The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Thread reference. But for synchronized native methods there could be more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819908946

From pchilanomate at openjdk.org  Tue Oct 29 00:04:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
 <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>
Message-ID: <KN4s68yO3KTnPYb3y0eMexToy1B3J9bOQPwDhbuDpk0=.7f3b8544-c22b-49ca-85c9-99dc99727c3a@github.com>

On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.
>
>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>>
> The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Thread reference. But for synchronized native methods there could be more.

> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change.
>
Because before this PR we never freezed interpreter frames belonging to native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819909304

From pchilanomate at openjdk.org  Tue Oct 29 00:04:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>
Message-ID: <Z-POFV3noL0adSkJwHIfc-RbkfBedii0V1qRp-WQ6Ws=.8fd850d2-de01-47bf-a44b-56c9bf5bf68a@github.com>

On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.
>
> The first sentence is not a sentence. Is it supposed to be saying:
> 
> // The first time we run after being preempted on Object.wait()
> // we check if we were interrupted or the wait timed-out ...
> 
> ?

Yes, I fixed the wording.

>> Only when facing contention on this call. But once we have the monitor we don't.
>
> But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

We will have the native wrapper frame at the top, but we still need to add some extra check to differentiate this `jni_enter()` case with respect to the case of facing contention on a synchronize native method, where we do allow to unmount (only when coming from the interpreter since the changes to support it where minimal). I used the NoPreemptMark here, but we could filter this case anywhere along the freeze path. Another option could be to check `thread->current_pending_monitor_is_from_java()` in the ObjectMonitor code before trying to preempt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921

From dlong at openjdk.org  Tue Oct 29 01:45:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 01:45:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:

> 75:     // Interpreter frames
> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only

This conflicts with sender_sp_offset.  Doesn't that cause a problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369

From dlong at openjdk.org  Tue Oct 29 02:02:26 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:02:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:

> 1349:   // set result handler
> 1350:   __ mov(result_handler, r0);
> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));

I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901

From dlong at openjdk.org  Tue Oct 29 02:12:25 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:12:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <qLIzGUcEFWFMi2Uckt0Yqnm8n85Vdjv8UWB-lti0m7o=.2a3d5139-a711-4dc9-a256-f2725be5fc2e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223:

> 221: }
> 222: 
> 223: void StubAssembler::epilogue(bool use_pop) {

Is there a better name we could use, like `trust_fp` or `after_resume`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640

From dlong at openjdk.org  Tue Oct 29 02:19:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:19:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <kAwXuYSJJfq0SijYJU_Ktw9tMf7lW1FRmXS581ZRmV8=.f836e40d-ec26-4b81-ad86-4e455bcd5727@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:

> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
> 642: #ifdef _LP64
> 643:   return r15_off / 2;

r15_off is a byte offset, so this returns a 16-bit short offset?  I think we need a comment here to explain the / 2 and what this returns.

src/hotspot/cpu/x86/frame_x86.cpp line 431:

> 429:   if (cb == Runtime1::blob_for(C1StubId::monitorenter_id) ||
> 430:       cb == Runtime1::blob_for(C1StubId::monitorenter_nofpu_id)) {
> 431:     thread_addr = (JavaThread**)(f.sp() + Runtime1::runtime_blob_current_thread_offset(f));

So this expects an offset in intptr_t units from runtime_blob_current_thread_offset(), but I thought it took a byte offset and then divided by 2.  I'm confused.

src/hotspot/share/c1/c1_Runtime1.hpp line 138:

> 136:   static void initialize_pd();
> 137: 
> 138:   static uint runtime_blob_current_thread_offset(frame f);

I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819983752
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522

From dlong at openjdk.org  Tue Oct 29 02:39:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:39:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <STXbA_YPsg6BunymS3r47wgamIcV5b_Zi-Bq8bFh_x4=.ff45571e-6c8c-45e7-ad8c-5eef3583d09e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:

> 357:   push_cont_fastpath();
> 358: 
> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.

>From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648

From dlong at openjdk.org  Tue Oct 29 02:49:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:49:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <TTF1D8Vo9G4KO-rN0Ut1vKIVFHvae1KBzR-5csVw73w=.cbdef9cc-4111-460e-9261-5e68d63475ad@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:

> 1507:     Label no_oop;
> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));

We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377

From sspitsyn at openjdk.org  Tue Oct 29 04:43:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 04:43:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:

> 1080:     } else {
> 1081:       assert(vthread != nullptr, "no vthread oop");
> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);

Nit: The name `oopCont` does not match the HotSpot naming convention.
       What about `cont_oop` or even better just `cont` as at the line 2550?

src/hotspot/share/prims/jvmtiExport.cpp line 1682:

> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));

I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

src/hotspot/share/prims/jvmtiExport.cpp line 2879:

> 2877:   JvmtiVTMSTransitionDisabler::start_VTMS_transition((jthread)vthread.raw_value(), /* is_mount */ true);
> 2878:   current->rebind_to_jvmti_thread_state_of(current->threadObj());
> 2879: }

This function looks a little bit unusual. I understand it is called
I need to think about the consequences but do not see anything bad so far.
I'll look at the `ObjectMonitor` and `continuation` side updates to get more details on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820012783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820052049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820062505

From alanb at openjdk.org  Tue Oct 29 06:36:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 06:36:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
Message-ID: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>

On Mon, 28 Oct 2024 19:16:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
> 
>> 527:      * execute the given {@code callable} under the current access
>> 528:      * control context, with the current context class loader as the
>> 529:      * context class loader. This method should normally be invoked
> 
> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820163200

From jwaters at openjdk.org  Tue Oct 29 07:02:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 07:02:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:

> 26: #include "runtime/sharedRuntime.hpp"
> 27: 
> 28: #ifdef _WIN64

Just a heads up: Due to a bug, this entire file is never used at all

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820188590

From dholmes at openjdk.org  Tue Oct 29 08:32:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 08:32:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
Message-ID: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>

On Mon, 28 Oct 2024 23:09:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.
>
> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
> 
> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820337946

From dholmes at openjdk.org  Tue Oct 29 09:51:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 09:51:10 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Hotspot changes look good. May be some further cleanup possible. A couple of queries.

Thanks

src/hotspot/os/windows/os_windows.cpp line 2615:

> 2613:   Thread* t = Thread::current_or_null_safe();
> 2614: 
> 2615: #if defined(_M_AMD64)

The check for LP64 on line 2622 below seems redundant now

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 87:

> 85:     volatile Thread* wrapperthread = thread;
> 86: 
> 87:     if (os::win32::get_thread_ptr_offset() == 0) {

I think `os::win32::get_thread_ptr_offset` is not needed now and  ./os_cpu/windows_x86/assembler_windows_x86.cpp looks like it can be deleted.

src/hotspot/share/adlc/adlc.hpp line 49:

> 47: #define strdup _strdup
> 48: 
> 49: #ifndef _INTPTR_T_DEFINED

This seems unnecessary these days.

src/hotspot/share/prims/jvm.cpp line 381:

> 379:   {
> 380: #undef CSIZE
> 381: #if defined(_LP64)

Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?

src/hotspot/share/prims/nativeLookup.cpp line 350:

> 348:   if (entry != nullptr) return entry;
> 349: 
> 350:   // 3) Try JNI short style without os prefix/suffix

Please update comment as there is no os prefix/suffix now

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:

> 53: #error unsupported platform
> 54: #endif
> 55: 

Does Windows Aarch64 define _LP64?

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2401144686
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820386150
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820407428
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820429621
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820433973
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820436924
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820441749

From shade at openjdk.org  Tue Oct 29 09:51:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 09:51:12 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
Message-ID: <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>

On Mon, 28 Oct 2024 23:15:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Launcher.gmk line 56:
>> 
>>> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>>> 55:       NAME := jaccessinspector, \
>>> 56:       EXTRA_SRC := \
>> 
>> I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?
>> 
>> Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.
>
> I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.

OK, good, as long as it was intentional.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820460415

From dholmes at openjdk.org  Tue Oct 29 09:51:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 09:51:13 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <5UIUxZr0j3KNUku45HGyyODTkrCo26CzAUr2zz0olnc=.22a6293d-0cd8-4fde-9832-ddcc539e4556@github.com>

On Mon, 28 Oct 2024 19:17:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os/windows/os_windows.cpp line 136:
> 
>> 134:   #define __CPU__ amd64
>> 135: #else
>> 136:   #define __CPU__ unknown
> 
> Should this be just `#error Unknown CPU`?

+1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820365629

From jwaters at openjdk.org  Tue Oct 29 09:55:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 09:55:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>

On Tue, 29 Oct 2024 09:32:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/share/prims/jvm.cpp line 381:
> 
>> 379:   {
>> 380: #undef CSIZE
>> 381: #if defined(_LP64)
> 
> Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?

It's something we do in our build. For us, _LP64 really means 64 bit

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820464097

From fbredberg at openjdk.org  Tue Oct 29 10:09:32 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 29 Oct 2024 10:09:32 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>

On Fri, 25 Oct 2024 13:11:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
>> 
>>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>>> 2032:     __ push_cont_fastpath();
>> 
>> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?
>
> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820487130

From alanb at openjdk.org  Tue Oct 29 10:40:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 10:40:14 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 246:

> 244:             CloseHandle(hProcess);
> 245:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException",
> 246:                 "Unable to attach to 32-bit process running under WOW64");

The comment just before this will need to be updated as the scenario as the tool side will always be 64-bit and just need to handle a 32-bit target VM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820548857

From mullan at openjdk.org  Tue Oct 29 12:40:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:40:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Update copyrights. Remove @compile line form Marshal.java test.
 - Update copyright headers
 - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
 - Merge branch 'master' into jep486
 - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
 - remove privileged calls in logging/File* tests
 - delete PermissionTest.java as it simply constructs provider impls
 - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
 - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
   Removed createPrivateValue(), no longer used.
 - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=04
  Stats: 66378 lines in 1872 files changed: 1145 ins; 61413 del; 3820 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From mullan at openjdk.org  Tue Oct 29 12:51:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:51:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
Message-ID: <InHcapZDPzV248KM-JZkB0e6iBp-skpVNJXkDdYazH0=.dd390d4d-e66f-4139-900a-a10410385483@github.com>

On Sun, 27 Oct 2024 00:15:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:
> 
>> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
>> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
>> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link
> 
> Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

This text was restored. See https://github.com/openjdk/jdk/pull/21498/commits/66145173cce201b655845144daa209a75ad5964a

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820732961

From mullan at openjdk.org  Tue Oct 29 12:52:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <WtTk6-HHt037cI-2dFzi2Xsah_0A7ceHMYjo_UI8t10=.7b75bce3-ff04-4cf5-a854-7cc54f4f94d1@github.com>

On Fri, 25 Oct 2024 19:55:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:
> 
>> 50: import com.foo.NumberFormatProviderImpl;
>> 51: 
>> 52: public class PermissionTest{
> 
> This test can be deleted entirely. What remains is just constructing each provider impl.
> The summary mentions a RuntimePermission and would need to be revised to a new description.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/8054d108fea3ce9e7f1618c3d90ef5af6cfa22d7

> test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:
> 
>> 155:     static class Configure {
>> 156:         static void setUp(Properties propertyFile) {
>> 157:             doPrivileged(() -> {
> 
> The doPrivileged() could be factored out.
> And callPrivileged().

These are all fixed in https://github.com/openjdk/jdk/pull/21498/commits/bc5b3d70741505a684a39474630372a9b2fd8bc0

> test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:
> 
>> 81:      * then the test is considered a success and passes.
>> 82:      *
>> 83:      * Note that 4sec may not be enough to detect issues if there are some.
> 
> Where is this timeout enforced or measured; this is just a comment, not a parameter.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/2a9b98e244362dbbb98487098865cfd46a46dc1e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820722883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820727624
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820725397

From mullan at openjdk.org  Tue Oct 29 12:52:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <kvSkNGGzpjSCrqcFcn_IfCM4LgffbPzAtH1WX1jHnmY=.da6d0dea-5296-4604-964c-f87b81486392@github.com>

On Fri, 25 Oct 2024 20:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:
> 
>> 46:             throw new RuntimeException("unexpected resource bundle");
>> 47:         }
>> 48: 
> 
> This main and TestPermission.java duplicate the basic resource location mechanisms.
> This test/Main.java an test/TestPermission can be removed entirely.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/cb5f6e43b891df8c2a977e665016079469290669

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820730316

From mullan at openjdk.org  Tue Oct 29 12:59:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
 <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
Message-ID: <-KKpAuNUa1hNQE1tPbw9tlG5LKTTS-L9r5_YSJNhAFw=.10315724-126e-42bc-a933-8cd854efc163@github.com>

On Tue, 29 Oct 2024 06:32:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
>> 
>>> 527:      * execute the given {@code callable} under the current access
>>> 528:      * control context, with the current context class loader as the
>>> 529:      * context class loader. This method should normally be invoked
>> 
>> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?
>
> That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.
> 
> Update: now fixed in sandbox

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0feceaae472710aa13e4c569f4d72d6149b7de07

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820738332

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <9nyF6shPmWaMMGsOnjrzYKlZApNJV1uhY-tsTQhi_-M=.021bd5d0-f978-4651-97d6-0ab3f7cb2eaf@github.com>

On Mon, 28 Oct 2024 21:02:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:
> 
>> 1: /*
> 
> Missed a copyright update; will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743852

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>

On Mon, 28 Oct 2024 21:00:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:
> 
>> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
>> 29:  * @compile -XDignore.symbol.file Marshal.java
>> 30:  * @run main/othervm/java.security.policy==test.policy Marshal
> 
> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.
> 
> Also, missing a copyright update, will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743569

From jwaters at openjdk.org  Tue Oct 29 13:17:16 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 13:17:16 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
Message-ID: <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>

On Tue, 29 Oct 2024 06:59:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
> 
>> 26: #include "runtime/sharedRuntime.hpp"
>> 27: 
>> 28: #ifdef _WIN64
> 
> Just a heads up: Due to a bug, this entire file is never used at all

I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820776554

From jwaters at openjdk.org  Tue Oct 29 13:30:23 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 13:30:23 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>

On Mon, 28 Oct 2024 19:25:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:
> 
>> 521: 
>> 522: extern "C" int SpinPause () {
>> 523: #ifdef AMD64
> 
> Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.

@shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820797875

From michaelm at openjdk.org  Tue Oct 29 13:44:31 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Oct 2024 13:44:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <Q1jPK8TnNv45P679HTgjg5q6q7BtdKvBymZQv4GCAug=.605e003e-9d6e-45f7-815c-1e8e5ff70959@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

I have reviewed the changes to the NIO selector/poller implementations and they look fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2444268747

From weijun at openjdk.org  Tue Oct 29 14:22:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Oct 2024 14:22:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>

On Mon, 28 Oct 2024 21:02:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
> 
>> 1: /*
> 
> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

It can removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820899380

From ihse at openjdk.org  Tue Oct 29 14:37:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:37:47 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v2]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <_vqxOwL91CU11rCTQQDOqQTaQmT6MryYl0X_wFrOVRw=.93503265-4579-4bb5-9bff-988ba152d96f@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove FIXMEs on x86 code that will soon go away anyway
 - Remove FIXME for issue resolved in JDK-8343167

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/a18d19c7..d5280f6d

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

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

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

From ihse at openjdk.org  Tue Oct 29 14:42:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <HB_BGygH9sWgvkyYjlKMuNV9saaCLojixNBvfRYF-As=.a2d3bb19-3856-429b-9957-f376471a8af7@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Use #error for unknown CPU
 - Restore PLATFORM_CHECK_DEPRECATION

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d5280f6d..c6b8771b

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

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

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

From shade at openjdk.org  Tue Oct 29 14:42:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
Message-ID: <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>

On Tue, 29 Oct 2024 13:26:57 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:
>> 
>>> 521: 
>>> 522: extern "C" int SpinPause () {
>>> 523: #ifdef AMD64
>> 
>> Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.
>
> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR

Submit a separate PR and implement this :) Pretty sure you'll get into some dark territories in Windows/AArch64, see how Linux/AArch64 does this. But honestly, this whole `extern "C"` mess should probably be cleaned up in favor of arch-specific stubs or something like that...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820935020

From ihse at openjdk.org  Tue Oct 29 14:42:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
 <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>
Message-ID: <EwBP8hZ_FRKS-4_Ga6GcYopwl-WcmnxB-E2SIso6JK0=.11afda7a-8fa7-44d5-a466-58a496067e65@github.com>

On Tue, 29 Oct 2024 09:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.
>
> OK, good, as long as it was intentional.

Yes, Erik is correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820936242

From ihse at openjdk.org  Tue Oct 29 14:47:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:47:15 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>
Message-ID: <JRryi28SiFM4QgEO9CcGegJJ4j3cPSEE_Z-IjJE_gkM=.aa94c03b-b08f-4c49-be7c-8b77a413136f@github.com>

On Mon, 28 Oct 2024 23:16:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>
> make/modules/jdk.accessibility/Lib.gmk line 34:
> 
>> 32: 
>> 33:   ##############################################################################
>> 34:   ## Build libjavaaccessbridge
> 
> Is double `##` intentional?

Well, yes and no. :-) I just copied the pattern I used elsewhere as a header to mark the output library name for `SetupJdkLibrary`. Now that you say this, I wonder why I started using `##`. Most of the places, but not all, use the double hash sign. Let's do this `##` for now as well, and then maybe I do another round of cross-makefile consistency and replace them all with single `#`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820945684

From dfuchs at openjdk.org  Tue Oct 29 14:47:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:47:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <5kPidtpO9u4Uq1Cjk3-caYGOFua3Q09ea4tO_2eVdKs=.90e9833e-9445-4545-93fc-f179230d6597@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Changes to System.LoggerFinder / System.getXxxLogger methods look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402138949

From ihse at openjdk.org  Tue Oct 29 14:47:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:47:16 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
Message-ID: <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>

On Tue, 29 Oct 2024 13:14:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
>> 
>>> 26: #include "runtime/sharedRuntime.hpp"
>>> 27: 
>>> 28: #ifdef _WIN64
>> 
>> Just a heads up: Due to a bug, this entire file is never used at all
>
> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown

What bug are you referring to that makes this file unused?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820946983

From dfuchs at openjdk.org  Tue Oct 29 14:52:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:52:13 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <cyX0-593hoAmv_MAHCQnjHRZFJywvIxuL4PTUWO7hLU=.82d77ccc-2e4f-4d7f-b2f9-08f07e3c9252@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I had a look at public classes in java/io; I am not a regular reviewer there but what I saw made sense to me. Changes to ObjectInputStream/ObjectOutputStream will need a more qualified Reviewer but I believe you have that already.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402160395

From ihse at openjdk.org  Tue Oct 29 14:58:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:49 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <UG02ofvpmG7U3kL6SDF5mrYdAwLWxIw9KB0Jt2_CKOA=.103e237e-2822-4c7f-a8fc-034f9763518c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
 - Merge branch 'master' into impl-JEP-479
 - Use #error for unknown CPU
 - Restore PLATFORM_CHECK_DEPRECATION
 - Remove FIXMEs on x86 code that will soon go away anyway
 - Remove FIXME for issue resolved in JDK-8343167
 - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port

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

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=03
  Stats: 1546 lines in 51 files changed: 66 ins; 1404 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From ihse at openjdk.org  Tue Oct 29 14:58:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <uXG3LZMkp8sbXbyPk_hCdTQw8lzshARy1wLw7_kuPjQ=.6ac51040-6926-4d6d-93a6-fb5f9c6710fd@github.com>

On Tue, 29 Oct 2024 09:46:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
>>  - Merge branch 'master' into impl-JEP-479
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>>  - Remove FIXMEs on x86 code that will soon go away anyway
>>  - Remove FIXME for issue resolved in JDK-8343167
>>  - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port
>
> Hotspot changes look good. May be some further cleanup possible. A couple of queries.
> 
> Thanks

@dholmes-ora 
> May be some further cleanup possible. 

If you have any suggestions, please let me know. Otherwise, we can clean it up afterwards as we encounter it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444509002

From jwaters at openjdk.org  Tue Oct 29 14:58:50 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
 <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
Message-ID: <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>

On Tue, 29 Oct 2024 14:44:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown
>
> What bug are you referring to that makes this file unused?

https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095864.html

This file isn't unused, I misspoke. Instead, it is meant as the implementation of frem and drem for Windows x64, but due to a bug, it's potentially being wrongly used as the implementation of frem and drem for Windows/ARM64 instead

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820964150

From jwaters at openjdk.org  Tue Oct 29 14:58:50 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
 <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>
Message-ID: <37HicUYBndPMWYfp1hWhVu7aTZzgbnCq1LFJCafbooc=.83838f4d-fe0a-4daf-962e-00764a2d7af0@github.com>

On Tue, 29 Oct 2024 14:37:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR
>
> Submit a separate PR and implement this :) Pretty sure you'll get into some dark territories in Windows/AArch64, see how Linux/AArch64 does this. But honestly, this whole `extern "C"` mess should probably be cleaned up in favor of arch-specific stubs or something like that...

Oh, I was thinking about Windows/x64, but I guess I can consider Windows/ARM64 too. I had a look at Linux/ARM64 actually, and it seems like it doesn't actually properly support SpinPause? It seems like it uses the overhead of a method call to "implement" SpinPause. I had a look at some example assembly that could potentially be used to implement it for Windows/ARM64, but I don't know if it's correct. If you want, we could continue this discussion elsewhere

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820959571

From ihse at openjdk.org  Tue Oct 29 14:58:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>
Message-ID: <yHGkV7I39TGK9UnDK3bHAzR1o-J1R44RTjqtMFl38OU=.f2f6733f-bbe7-4363-b704-3c59b94ebb24@github.com>

On Tue, 29 Oct 2024 10:37:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
>>  - Merge branch 'master' into impl-JEP-479
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>>  - Remove FIXMEs on x86 code that will soon go away anyway
>>  - Remove FIXME for issue resolved in JDK-8343167
>>  - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port
>
> src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 246:
> 
>> 244:             CloseHandle(hProcess);
>> 245:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException",
>> 246:                 "Unable to attach to 32-bit process running under WOW64");
> 
> The comment just before this will need to be updated as the scenario as the tool side will always be 64-bit and just need to handle a 32-bit target VM.

Good catch. I also simplified the code, now that we know that our process is 64 bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820966986

From dfuchs at openjdk.org  Tue Oct 29 15:03:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:03:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <MlrAktPp9rmUHEnK3fWUbAH3j7eY0jZ0AzLMzRbSo_0=.34e5e56f-ef85-46e5-a92d-717a95e7a38e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I have reviewed changes in the public classes in java/nio/channels and java/nio/channels/spi. They LGTM.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402192169

From ihse at openjdk.org  Tue Oct 29 15:05:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:05:09 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v5]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <h7H4LK5VJzr9g1OkY2MRfS2m9uYuiAfJCIN-l7QCd6o=.1c385cf9-88c8-474f-809d-66f003f1bf39@github.com>

On Tue, 29 Oct 2024 09:34:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NativeLookup::lookup_entry
>
> src/hotspot/share/prims/nativeLookup.cpp line 350:
> 
>> 348:   if (entry != nullptr) return entry;
>> 349: 
>> 350:   // 3) Try JNI short style without os prefix/suffix
> 
> Please update comment as there is no os prefix/suffix now

Actually, it was not just the comment that were wrong, it was the actual code ("if the comment and code don't agree, then most likely both are wrong").

The steps 3 and 4 were just 1 and 2 without the os prefix/suffix, which we do not need anymore. I removed 4 but for some reason I did not realize that I should remove 3 as well. And I kept an unnecessary `if (entry != nullptr) return entry;`...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820979841

From ihse at openjdk.org  Tue Oct 29 15:05:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:05:08 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v5]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <xc9ltNT-rdGYdDu0ZqrW2crALMC7ebbR06McQYzcul4=.9a1da15f-a2f1-456e-93aa-3c35678afdfb@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix NativeLookup::lookup_entry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/01675824..bfca62ea

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

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

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

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <k-eEHHXkyAYvaSww-guyHgnfZPcju5V0wakhdvPICXY=.d96a3d1d-c949-4937-b1d3-2cfe088040f8@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove windows-only code guarded by _LP64.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/bfca62ea..d7ceff48

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

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

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

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>

On Tue, 29 Oct 2024 09:02:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove windows-only code guarded by _LP64.
>
> src/hotspot/os/windows/os_windows.cpp line 2615:
> 
>> 2613:   Thread* t = Thread::current_or_null_safe();
>> 2614: 
>> 2615: #if defined(_M_AMD64)
> 
> The check for LP64 on line 2622 below seems redundant now

Indeed, nice catch! I also found another place in this file that were guarded by `_LP64` that I removed. I also did a grep on `LP64` in `hotspot/os/windows`, but there were no more instances.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820994278

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
 <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
 <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>
Message-ID: <yQgyCT9A0hSBXlsdUnqqdcBzQEfwjmAsB61B9tiSbp8=.ea446cda-6125-45e8-a1a5-addab6adabe7@github.com>

On Tue, 29 Oct 2024 14:53:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> What bug are you referring to that makes this file unused?
>
> https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095864.html
> 
> This file isn't unused, I misspoke. Instead, it is meant as the implementation of frem and drem for Windows x64, but due to a bug, it's potentially being wrongly used as the implementation of frem and drem for Windows/ARM64 instead

Okay. I'll leave it to you to sort out that mess. :) But afaict from reading up on the discussion, this removal of `_WIN64` does not change anything in that respect, so I'll keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820986323

From ihse at openjdk.org  Tue Oct 29 15:19:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:19:02 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v7]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <TRqrMAD-Pk6wNKVS4nls_GOxV-vNS_P7tADiYOda0JE=.5adf838c-92d3-467f-916e-f7655bf841a0@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove win32-specific implementation of MacroAssembler::get_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d7ceff48..c69e804f

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

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

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

From ihse at openjdk.org  Tue Oct 29 15:19:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:19:03 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v7]
In-Reply-To: <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>
Message-ID: <tWm2tu5KM8KzVRFTLKQCQ_ld1ByLbgNf3PqSMcv3l3k=.5f9b14a8-1447-4653-b688-30bcf4caad3d@github.com>

On Tue, 29 Oct 2024 15:08:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 2615:
>> 
>>> 2613:   Thread* t = Thread::current_or_null_safe();
>>> 2614: 
>>> 2615: #if defined(_M_AMD64)
>> 
>> The check for LP64 on line 2622 below seems redundant now
>
> Indeed, nice catch! I also found another place in this file that were guarded by `_LP64` that I removed. I also did a grep on `LP64` in `hotspot/os/windows`, but there were no more instances.

... however, there is also `hotspot/os_cpu/windows_x86` to check, and there I also found another instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821007811

From ihse at openjdk.org  Tue Oct 29 15:26:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:26:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v8]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <2dt6agS27uUAXYsVQh4B6qvuk0KNiouPyH9bQQv8Kiw=.bb927982-e3f8-4276-8068-b2f97508ce50@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove thread_ptr_offset remnants

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/c69e804f..fdec8b1f

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

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

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

From ihse at openjdk.org  Tue Oct 29 15:29:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:29:20 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v8]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <LUMCIYXGDty5ON_qg-m5S7JM7jqppr2Rn_G4GMKJr3U=.02d9577e-b074-480f-99e0-79837b2d191b@github.com>

On Tue, 29 Oct 2024 09:16:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove thread_ptr_offset remnants
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 87:
> 
>> 85:     volatile Thread* wrapperthread = thread;
>> 86: 
>> 87:     if (os::win32::get_thread_ptr_offset() == 0) {
> 
> I think `os::win32::get_thread_ptr_offset` is not needed now and  ./os_cpu/windows_x86/assembler_windows_x86.cpp looks like it can be deleted.

I just redisovered this by myself from your previous comment. :) However, there were some more `thread_ptr_offset` I could remove.

`assembler_windows_x86.cpp` is heavily cut down, but can't be fully removed since it contains the Windows implementation of `MacroAssembler::int3()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821037756

From ihse at openjdk.org  Tue Oct 29 15:33:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:33:51 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v9]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Ukgge4Lp1838MvKUyBYfxuZnSZuhTSnBZZ_z8jhC3mQ=.3856c7ca-fc8a-4f65-9962-7e14b6c1c1b7@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clean up old Windows workarounds in adlc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fdec8b1f..e5673077

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

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

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

From ihse at openjdk.org  Tue Oct 29 15:33:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:33:51 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v9]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>

On Tue, 29 Oct 2024 09:37:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up old Windows workarounds in adlc
>
> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:
> 
>> 53: #error unsupported platform
>> 54: #endif
>> 55: 
> 
> Does Windows Aarch64 define _LP64?

Yes. As Julian says, it's something we set up in our builds:

  if test "x$FLAGS_CPU_BITS" = x64; then
    $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
    $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
  fi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821060520

From dfuchs at openjdk.org  Tue Oct 29 15:39:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:39:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <ytVM17GPcnPoj29Blt9_kjjl-DLdbG_ixtEsUzamNx8=.55080c4c-0e5b-4f23-8052-889754c55b2e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

For the record I have also reviewed the changes in JNDI (sources + test) and HTTP server (sources, I did the test changes) and they look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2444638665

From ihse at openjdk.org  Tue Oct 29 15:54:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:54:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v10]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <fH9Jl-bVpl3jA6kajM66-sA2r0DZqzhJrHcsU-9fJ_w=.7492ce8b-024a-4823-88fc-65fb80415424@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  adlc build were missing _CRT_DECLARE_NONSTDC_NAMES

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/e5673077..afb50971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 16:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:01:49 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  IS_WIN64 is never used and can be completely removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/afb50971..9df6cb93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From jwaters at openjdk.org  Tue Oct 29 16:07:26 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 16:07:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <vrcs6_LQPTzV0Qer4akLdyVLHDYPSnLZo7ghbX0PUzw=.de57d630-4d94-4e42-80be-1e964a492e61@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Just a heads up, don't merge master for the time being. I think 8341527 just broke the x86 assembler

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444710777

From ihse at openjdk.org  Tue Oct 29 16:07:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:07:27 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <jOSFV149kokCQvuprsHXfI74yE9iZ1B7pkKHYkna5OM=.a29556ce-7517-4b45-b1cd-69e9508c1005@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Yeah, this still needs JEP-479 to be targeted, so it some time away from being merged. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444716198

From jwaters at openjdk.org  Tue Oct 29 16:16:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 16:16:13 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <ktWFCYs7bD74riBdfCL7E1Y1cUYLh2IYq67MVeulTs8=.8eb18c32-ac62-48d2-8cb9-a9658d0cb4b7@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Oh, I meant don't merge current master into the branch for this PR haha, you'll very likely get red all over your GHA from the broken assembler_x86.cpp failing to compile (From what I can tell, all x86 builds are affected)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444736299

From alanb at openjdk.org  Tue Oct 29 16:16:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 16:16:14 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <w2A4lfSmBnNKSd2qB0q2TQvxB7209_sf9_q97k8enWk=.09b9ef8a-402a-4cb6-8160-73047fea80ff@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 236:

> 234:      * On Windows we need to handle 32-bit tools trying to attach to 64-bit
> 235:      * processes, which is currently not supported by this implementation.
> 236:      */

The tool side uses the attach API so the potential scenario is a tool on 64-bit attempting to attach to a target VM that is 32-bit. So the comment needs to re-phased to the reverse of what it says now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821145158

From ihse at openjdk.org  Tue Oct 29 16:35:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:35:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v12]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <tMqPWYRUTPtyZmNJ4RkRM7eEw5OFs3_eXY1AyZNzoSU=.ffb49543-18df-4b01-8de0-391cd82dd751@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  adlc need _CRT_NONSTDC_NO_WARNINGS as well... *sigh*

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/9df6cb93..7eb46c33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=10-11

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From rriggs at openjdk.org  Tue Oct 29 16:54:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 16:54:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <Pg9N43cJQ4mPhIHzrotEbgDy4oCc1OcfEDWoP9U8aVI=.11981767-6704-4655-beb0-7b6c7d7b8bc9@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed java.sql and java.sql.rowset src and test; lgtm

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402558624

From honkar at openjdk.org  Tue Oct 29 17:10:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>

On Thu, 24 Oct 2024 15:03:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1613:
> 
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
>> 1613:      * If the specified property is not found then null is returned instead.
> 
> Suggestion:
> 
>      * If the specified property is not found, null is returned instead.
> 
> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

Updated on jep486 branch

> src/java.desktop/share/classes/java/awt/Font.java line 1781:
> 
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
>> 1781:      * If the specified property is not found then the {@code font}
> 
> Suggestion:
> 
>      * If the specified property is not found, the {@code font}

Updated on jep486 branch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821237100
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821236441

From honkar at openjdk.org  Tue Oct 29 17:10:55 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>

On Thu, 24 Oct 2024 15:12:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:
> 
>> 66:      * @throws SecurityException if a security manager exists and its
>> 67:      *            {@code checkPermission} method doesn't allow the operation
>> 68:      * @see       GraphicsConfiguration
> 
> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

You are right, I see it mentioned already in the doc. I don't think we need to mention it again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821232103

From bchristi at openjdk.org  Tue Oct 29 18:38:54 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Oct 2024 18:38:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

`java.util` and `java.util.concurrent` src and test changes look good.

src/java.base/share/classes/java/util/concurrent/Executors.java line 392:

> 390:     /**
> 391:      * Returns a thread factory used to create new threads that
> 392:      * have current context class loader as the context class loader.

One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402793417
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821358523

From rriggs at openjdk.org  Tue Oct 29 18:49:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 18:49:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <gYQw-g86W7MLIsSAkOIYq5Y3HjssUtl3_xxeYVHGV74=.3a600d88-7674-4014-bae5-65691f06af21@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Reviewed java/util/jar,zip src and test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402819301

From pchilanomate at openjdk.org  Tue Oct 29 18:57:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 18:57:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment in SharedRuntime::generate_native_wrapper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/056d21ec..3e8b4fe6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=15-16

  Stats: 15 lines in 3 files changed: 6 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 29 19:08:35 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:35 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
 <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>
Message-ID: <S0IfxODyOvrNooBjR0lhlgrGg1zHFmID_7LfL0W8uFo=.5524316f-3234-492f-bd73-9a2a2c37fb21@github.com>

On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.
> 
> Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.
>
After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760

From pchilanomate at openjdk.org  Tue Oct 29 19:08:36 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
Message-ID: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>

On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>>
>> It will just move the task of adjusting the size of the frame somewhere else.
>
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
> 
> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:


   0xffffdfdba584:	sub	sp, sp, #0x10
   0xffffdfdba588:	stp	x29, x30, [sp]
   0xffffdfdba58c:	ldrb	w8, [x28, #1192]
   0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
   0xffffdfdba594:	mov	x8, #0x4ba0                	
   0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
   0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5a0:	mov	x0, x28
   0xffffdfdba5a4:	blr	x8
   0xffffdfdba5a8:	mov	x9, sp
   0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
   0xffffdfdba5b0:	mov	x0, x1
   0xffffdfdba5b4:	mov	x1, x2
   0xffffdfdba5b8:	mov	x2, x28
   0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
   0xffffdfdba5c0:	mov	x8, #0xe6a4                	
   0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
   0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
   0xffffdfdba5d0:	blr	x8
   0xffffdfdba5d4:	nop
   0xffffdfdba5d8:	movk	xzr, #0x0
   0xffffdfdba5dc:	movk	xzr, #0x0
   0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
   0xffffdfdba5e4:	str	xzr, [x28, #1000]
   0xffffdfdba5e8:	str	xzr, [x28, #1008]
   0xffffdfdba5ec:	ldr	x10, [x28, #8]
   0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
   0xffffdfdba5f4:	ldp	x29, x30, [sp]
   0xffffdfdba5f8:	add	sp, sp, #0x10
   0xffffdfdba5fc:	ret
   0xffffdfdba600:	ldp	x29, x30, [sp]
   0xffffdfdba604:	add	sp, sp, #0x10
   0xffffdfdba608:	adrp	x8, 0xffffdfc30000
   0xffffdfdba60c:	add	x8, x8, #0x80
   0xffffdfdba610:	br	x8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821389434

From pchilanomate at openjdk.org  Tue Oct 29 19:08:37 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
Message-ID: <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>

On Tue, 29 Oct 2024 01:42:09 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
> 
>> 75:     // Interpreter frames
>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
> 
> This conflicts with sender_sp_offset.  Doesn't that cause a problem?

No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856

From pchilanomate at openjdk.org  Tue Oct 29 19:08:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>
Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.98c3e8da-5fa4-4653-8254-a80b9c86ec8e@github.com>

On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.
>
> It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

I updated the comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821386261

From pchilanomate at openjdk.org  Tue Oct 29 19:08:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
 <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>
Message-ID: <E5BoDn6nBa-B8W6bUd-RciLLaEMNTcF4YVT2JlpCXGg=.71b49a14-9e2c-47a2-98d7-f4df8bbf7ae1@github.com>

On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
>> 
>> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.
>
> Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

It's not that straightforward because the freeze can fail. By then we would have already started the wait call as a virtual thread though, not a platform thread. Maybe we could try to freeze before the wait0 call. We always have the option to use a flag in the method as Dean suggests instead of checking for a specific one. Since now there is only `Object.wait()` I think it's better to explicitly check for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821391532

From dlong at openjdk.org  Tue Oct 29 19:44:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 19:44:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <JjAMYDu2JWAGBmPXC8__9R4OhWr43Y-L5qksWcCJAzQ=.749fcb0e-2e47-4816-8564-ec23ad4d80d2@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324:

> 322:   movq(scrReg, tmpReg);
> 323:   xorq(tmpReg, tmpReg);
> 324:   movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset()));

I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823

From ihse at openjdk.org  Tue Oct 29 20:22:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 20:22:03 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/7eb46c33..3556bec5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From dlong at openjdk.org  Tue Oct 29 20:42:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 20:42:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
Message-ID: <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>

On Tue, 29 Oct 2024 18:57:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in SharedRuntime::generate_native_wrapper

src/hotspot/share/code/nmethod.cpp line 712:

> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185

From dlong at openjdk.org  Tue Oct 29 20:45:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 20:45:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
Message-ID: <7IcqtCURSggJ3TfKrTorRcFaCrbLsWworFGrFolak7k=.8348725c-581b-4d75-ac69-db1b53386497@github.com>

On Tue, 29 Oct 2024 18:57:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in SharedRuntime::generate_native_wrapper

src/hotspot/share/code/nmethod.cpp line 1302:

> 1300:     _compiler_type           = type;
> 1301:     _orig_pc_offset          = 0;
> 1302:     _num_stack_arg_slots     = 0;

Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576

From dlong at openjdk.org  Tue Oct 29 21:00:30 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:00:30 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
 <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
Message-ID: <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>

On Tue, 29 Oct 2024 19:04:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
>> 
>>> 75:     // Interpreter frames
>>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
>> 
>> This conflicts with sender_sp_offset.  Doesn't that cause a problem?
>
> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

`sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020

From dlong at openjdk.org  Tue Oct 29 21:35:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/oops/method.cpp line 870:

> 868: }
> 869: 
> 870: bool Method::is_object_wait0() const {

It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267

From bpb at openjdk.org  Tue Oct 29 21:40:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Oct 2024 21:40:23 GMT
Subject: RFR: 8343234: (bf) Remove java/nio/Buffer/LimitDirectMemory.java from
 problem list
Message-ID: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>

It has not been possible to reproduce this problem via local or CI tests so removing it from the problem list would allow more information to be gathered should it continue to fail.

-------------

Commit messages:
 - 8343234: (bf) Remove java/nio/Buffer/LimitDirectMemory.java from problem list

Changes: https://git.openjdk.org/jdk/pull/21773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343234
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21773/head:pull/21773

PR: https://git.openjdk.org/jdk/pull/21773

From bpb at openjdk.org  Tue Oct 29 21:40:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Oct 2024 21:40:23 GMT
Subject: RFR: 8343234: (bf) Remove java/nio/Buffer/LimitDirectMemory.java
 from problem list
In-Reply-To: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
References: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
Message-ID: <YT8dgknioKN40zMZU8EytCTaPwjHqbLgvfr2DFsbAbY=.8a819b82-816d-458d-846d-9af92d4079e2@github.com>

On Tue, 29 Oct 2024 21:31:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It has not been possible to reproduce this problem via local or CI tests so removing it from the problem list would allow more information to be gathered should it continue to fail.

The most recent failures have been confined to Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21773#issuecomment-2445368716

From dlong at openjdk.org  Tue Oct 29 21:49:31 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:49:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <7tWdvN9ESrXL9_I6SoEXaHFInONVH4WK9cCBv2mISUg=.6d6b1da1-18c1-4ff5-91d2-601db5aab0ed@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:

> 253:                          RegisterMap::WalkContinuation::include);
> 254:     full_map.set_include_argument_oops(false);
> 255:     closure->do_frame(f, map);

This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623

From pchilanomate at openjdk.org  Tue Oct 29 22:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v18]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <0oRznkXzZMzer7mrnFTMa2iQhQA8CtBqez5UQKv1LnY=.19c17526-c482-4ac2-b72e-a3a02749a395@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add comments for Dean + move reload result_handler in generate_native_entry
 - add assert in ThawBase::recurse_thaw_interpreted_frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/3e8b4fe6..0f3b9021

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=16-17

  Stats: 15 lines in 6 files changed: 10 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 29 22:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
Message-ID: <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>

On Tue, 29 Oct 2024 01:59:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:
> 
>> 1349:   // set result handler
>> 1350:   __ mov(result_handler, r0);
>> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));
> 
> I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

Added comment.

> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:
> 
>> 1507:     Label no_oop;
>> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
>> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));
> 
> We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

Moved.

> src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:
> 
>> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
>> 642: #ifdef _LP64
>> 643:   return r15_off / 2;
> 
> I think using r15_offset_in_bytes() would be less confusing.

I copied the same comments the other platforms have to make it more clear.

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
> 
>> 357:   push_cont_fastpath();
>> 358: 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 
> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

> src/hotspot/share/c1/c1_Runtime1.hpp line 138:
> 
>> 136:   static void initialize_pd();
>> 137: 
>> 138:   static uint runtime_blob_current_thread_offset(frame f);
> 
> I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591515
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593810
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821592920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930

From pchilanomate at openjdk.org  Tue Oct 29 22:19:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>
Message-ID: <zhJLtXdHx6wG6RjM643rdNM2ddMbk06Arw1B2CsUQ2k=.1585d596-6a33-4d8f-9b34-8a792736a4fb@github.com>

On Mon, 28 Oct 2024 21:07:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:
> 
>> 144:   // Make sure that locals is already relativized.
>> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
>> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)
> 
> What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

It's for the 2 extra words for native methods (temp oop/result handler). Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591143

From pchilanomate at openjdk.org  Tue Oct 29 22:19:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
Message-ID: <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>

On Tue, 29 Oct 2024 20:39:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment in SharedRuntime::generate_native_wrapper
>
> src/hotspot/share/code/nmethod.cpp line 712:
> 
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
>> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

I added a comment already in `vthread_monitor_waited_event()` in ObjectMonitor.cpp. I think it's better placed there.

> src/hotspot/share/code/nmethod.cpp line 1302:
> 
>> 1300:     _compiler_type           = type;
>> 1301:     _orig_pc_offset          = 0;
>> 1302:     _num_stack_arg_slots     = 0;
> 
> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264

From dlong at openjdk.org  Tue Oct 29 22:19:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <v4Y7AuP0UB6uU5ayYuBsziKB-Zac8Aj0LJ-me8nI9Qo=.ebce824f-37e5-4864-b75b-f5f9604474b3@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnv.cpp line 1363:

> 1361:   }
> 1362: 
> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {

Do we need to check for `java_thread == nullptr` for other locking modes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124

From dlong at openjdk.org  Tue Oct 29 22:26:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:26:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <taG8411IReqDKGmD3YXSdAX4iiPoUTixbnHUQNA0sOM=.10e86e63-bd4f-4890-bfe8-51e58a692402@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:

> 1600:           // If the thread was found on the ObjectWaiter list, then
> 1601:           // it has not been notified.
> 1602:           Handle th(current_thread, w->threadObj());

Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480

From dlong at openjdk.org  Tue Oct 29 22:49:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:49:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <iJbJpOi1IJf3dZ-d0n8z0a1HC97wsFvR8kgXvOnO-PA=.7a2f27b4-ffa4-4112-acd7-055fd16fcd3b@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.toPreemptStatus() in Continuation.java

I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785

From dlong at openjdk.org  Tue Oct 29 22:55:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:55:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <Iy8BxuaNQ1xnGaF-KmfsxnKdkV7mCMlkIBgdoPRiONU=.291a33a1-160d-4579-ba2b-795465d4d37e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationEntry.cpp line 51:

> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;

I don't see why we need these relative offsets.  Instead of doing

_thaw_call_pc_offset = __ pc() - start;

why not do

_thaw_call_pc = __ pc();

The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432

From dlong at openjdk.org  Tue Oct 29 23:01:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:01:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:

> 314:     pc = ContinuationHelper::return_address_at(
> 315:            sp - frame::sender_sp_ret_address_offset());
> 316:   }

You could do this with an overload instead:

static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) {
  assert(pc != nullptr, "");
  [...]
}
static void set_anchor(JavaThread* thread, intptr_t* sp) {
  address pc = ContinuationHelper::return_address_at(
    sp - frame::sender_sp_ret_address_offset());
  set_anchor(thread, sp, pc);
}

but the compiler probably optmizes the above check just fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036

From dlong at openjdk.org  Tue Oct 29 23:08:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:08:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:

> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;

`cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152

From dlong at openjdk.org  Tue Oct 29 23:15:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:15:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <i04QzOl9bIYXpYJGAD7n61f8kRdEtp2FR55sLcK4oUc=.da12b6ff-0527-4b08-a171-fa5e6af37d37@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:

> 1061:   unwind_frames();
> 1062: 
> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);

It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581

From dlong at openjdk.org  Tue Oct 29 23:19:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:19:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:

> 1409:     // zero out fields (but not the stack)
> 1410:     const size_t hs = oopDesc::header_size();
> 1411:     oopDesc::set_klass_gap(mem, 0);

Why, bug fix or cleanup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040

From dlong at openjdk.org  Tue Oct 29 23:23:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:23:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <KDT7bMjVw0N91OMe8OaAdjS2obawYpv6VkNO8vLUhMY=.dc5d87b7-7000-4477-9200-83cf14df8f15@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659:

> 1657:   int i = 0;
> 1658:   for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) {
> 1659:     if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) {

OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194

From dlong at openjdk.org  Tue Oct 29 23:27:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:27:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <XJWMMcQer9q8ZFBxU-TrPlXOu7rG3fnEabQIpavaWok=.abf4c6b4-d28f-4c49-a2ad-5b02fee39f33@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:

> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)

So this means it's OK to over-estimate the size here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267

From dlong at openjdk.org  Tue Oct 29 23:52:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:52:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <hbNGY5tBwNUnWHk1JH-5re8wRI8yPoSRzsVJy_y5pE8=.ea49eee0-45a6-42c2-84d1-5e8be3c257d5@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:

> 2060:   }
> 2061: 
> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);

Suggestion:

  f.next(SmallRegisterMap::instance(), true /* stop */);

This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778

From dlong at openjdk.org  Wed Oct 30 00:19:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:19:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <FdLVhmsz11XwyK4LSofGiYbWLpD5hwuC8OKg4uSL0-A=.29d607fe-6e23-4722-9520-fa639fe93cfc@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:

> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
> 2649:   } else {
> 2650:     _stream.next(SmallRegisterMap::instance);

Suggestion:

    _stream.next(SmallRegisterMap::instance());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316

From pchilanomate at openjdk.org  Wed Oct 30 00:44:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 00:44:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add klass_name check for is_object_wait0
 - Fix comment in continuation.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0f3b9021..9fd4c036

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=17-18

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 00:44:17 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 00:44:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>
Message-ID: <cWO4-UKVH-sGiJQDYO3nmH0HBnP8daGHGxouNARu9P4=.91bbac48-3977-4a4a-90ac-27750b4e196b@github.com>

On Tue, 29 Oct 2024 21:32:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/oops/method.cpp line 870:
> 
>> 868: }
>> 869: 
>> 870: bool Method::is_object_wait0() const {
> 
> It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

Right, I added a check for the klass too.

> src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:
> 
>> 253:                          RegisterMap::WalkContinuation::include);
>> 254:     full_map.set_include_argument_oops(false);
>> 255:     closure->do_frame(f, map);
> 
> This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

The full map gets only populated once we get the sender. We only need it when processing the caller which needs to know where each register was spilled since it might contain an oop.

> src/hotspot/share/prims/jvmtiEnv.cpp line 1363:
> 
>> 1361:   }
>> 1362: 
>> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {
> 
> Do we need to check for `java_thread == nullptr` for other locking modes?

No, both LM_LIGHTWEIGHT and LM_MONITOR have support for virtual threads. LM_LEGACY doesn't, so if the virtual thread is unmounted we know there is no monitor information to collect.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:
> 
>> 1600:           // If the thread was found on the ObjectWaiter list, then
>> 1601:           // it has not been notified.
>> 1602:           Handle th(current_thread, w->threadObj());
> 
> Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

We already filtered virtual threads above so no point in calling get_vthread_or_thread_oop() again. They will actually return the same result though.

> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.toPreemptStatus() in Continuation.java
> 
> I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

Should be just PreemptStatus. Fixed.

> src/hotspot/share/runtime/continuationEntry.cpp line 51:
> 
>> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
>> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
>> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;
> 
> I don't see why we need these relative offsets.  Instead of doing
> 
> _thaw_call_pc_offset = __ pc() - start;
> 
> why not do
> 
> _thaw_call_pc = __ pc();
> 
> The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

But these are generated in a temporary buffer. Until we call nmethod::new_native_nmethod() we won't know the final addresses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695964
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821697629
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698318
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155

From dlong at openjdk.org  Wed Oct 30 00:55:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:55:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
 <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>
Message-ID: <PTE67iiSpLLs5DWzn4rJE6FjIZyA-4G_i-xUdJdLIrE=.744a6de2-625e-491b-a3f6-14bc17a2e168@github.com>

On Tue, 29 Oct 2024 22:12:56 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
>> 
>>> 357:   push_cont_fastpath();
>>> 358: 
>>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 
>> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.
>
> Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

OK, I was looking for where it stores it in the anchor, but it doesn't, at least not until make_walkable() is called.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135

From dlong at openjdk.org  Wed Oct 30 00:55:30 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:55:30 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:

> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 360:   lea(rscratch1, resume_pc);
> 361:   push(rscratch1);

Suggestion:

  push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030

From dlong at openjdk.org  Wed Oct 30 01:55:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 01:55:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.PreemptStatus() in Continuation.java

As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421

From dlong at openjdk.org  Wed Oct 30 02:09:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 02:09:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <v_0xCKqgq9wJzy9ttitKZgC87K6GagkmPa6EOhdu1Ec=.637a00ad-7be5-485f-b44d-9858389cfec7@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:

> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
> 2045:     // frame effectively overwritting the restored registers during that call.

Suggestion:

    // frame effectively overwriting the restored registers during that call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997

From dholmes at openjdk.org  Wed Oct 30 02:21:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 02:21:11 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
Message-ID: <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>

On Tue, 29 Oct 2024 15:30:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:
>> 
>>> 53: #error unsupported platform
>>> 54: #endif
>>> 55: 
>> 
>> Does Windows Aarch64 define _LP64?
>
> Yes. As Julian says, it's something we set up in our builds:
> 
>   if test "x$FLAGS_CPU_BITS" = x64; then
>     $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
>     $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
>   fi

Ugghh! I was thrown by the `x` in test expressions and thought `x64` meant, well, x64 :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821763177

From dholmes at openjdk.org  Wed Oct 30 02:27:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 02:27:13 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

Hotspot updates look good.

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 382:

> 380:                  i, xmm[1], xmm[0]);
> 381:   }
> 382:   st->print("  MXCSR=" UINT32_FORMAT_X_0, uc->MxCsr);

Is this moved from somewhere else?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2403423258
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821766707

From kbarrett at openjdk.org  Wed Oct 30 03:44:23 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Oct 2024 03:44:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

I didn't spend much time looking for more places that could use updating.  We can
always do more cleaning up later if more are found.

make/scripts/compare.sh line 79:

> 77: 
> 78: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
> 79:   DIS_DIFF_FILTER="$SED -r \

This is now being defined for windows-aarch64 too, when it previously wasn't.  Is that intentional?

make/scripts/compare.sh line 1457:

> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"

This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
given the "x64" suffix.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1433:

> 1431:   // instructions that are SP relative. After the jni call we switch to FP
> 1432:   // relative instructions instead of re-adjusting the stack on windows.
> 1433:   // ****************************************************************************

I think it might be better to keep this comment.  It might be helpful information for someone who
needs to touch this code between now and when we remove all 32bit x86 support (which might
be soonish, but not immediate).  And this comment will go away when that change happens.

src/hotspot/os/windows/os_windows.cpp line 2592:

> 2590:   ctx->Rdx = (DWORD)0;             // remainder
> 2591:   // Continue the execution
> 2592: #else

Maybe retain `#else` clause as an `#error`?

src/hotspot/share/adlc/main.cpp line 494:

> 492: }
> 493: 
> 494: #if !defined(_WIN32) || defined(_WIN64)

Removing the conditionalization is fine for this change.  But see also 
https://bugs.openjdk.org/browse/JDK-8342639
I've added a note there that this change removed the conditionalization.

src/java.base/windows/native/libjava/gdefs_md.h line 31:

> 29: 
> 30: #include <stddef.h>
> 31: #ifndef _WIN64

I suspect the unix/windows gdefs_md.h files could be eliminated, and just make gdefs.h use portable
headers.  That can be done as a separate cleanup.

src/java.base/windows/native/libjava/jlong_md.h line 66:

> 64: #define jlong_zero_init ((jlong) 0)
> 65: 
> 66: #ifdef _WIN64

After this change I think the differences between the unix and windows variants of this file are trivial
and could be resolved in favor of moving everything directly into jlong.h.  Though note there are some
places in java.desktop that currently directly include jlong_md.h.  This can be done as a separate cleanup.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2403283976
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821670031
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821671116
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821680493
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821684248
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821796117
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821806395
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821809957

From kbarrett at openjdk.org  Wed Oct 30 03:44:24 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Oct 2024 03:44:24 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
Message-ID: <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>

On Tue, 29 Oct 2024 09:51:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 381:
>> 
>>> 379:   {
>>> 380: #undef CSIZE
>>> 381: #if defined(_LP64)
>> 
>> Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?
>
> It's something we do in our build. For us, _LP64 really means 64 bit

It seems like the `_WIN64` check here was never useful.  It's also been there since before the
mercurial age.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821799991

From sundar at openjdk.org  Wed Oct 30 07:38:48 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 30 Oct 2024 07:38:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <KpTjC3N9OKmhZehKUPHo3hDuxCaNLC2rP9VYkWvCDIo=.d2ad268f-39af-4b60-9fc1-f6546a85f7ed@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I reviewed jdk.dynalink changes. LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2403864492

From sspitsyn at openjdk.org  Wed Oct 30 09:48:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Oct 2024 09:48:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuation.cpp line 88:

> 86:       if (_target->has_async_exception_condition()) {
> 87:         _failed = true;
> 88:       }

Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

src/hotspot/share/runtime/continuation.cpp line 115:

> 113:       if (jvmti_present) {
> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
> 115:         if (JvmtiExport::should_post_vthread_mount()) {

This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512

From ihse at openjdk.org  Wed Oct 30 10:45:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 10:45:15 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>
Message-ID: <HtcDnWKURWPMw0ukH8HXBHIfisML2RUl_Md5_8EBRXY=.c3cec63e-ca03-4078-b4ed-b1b5682266ee@github.com>

On Wed, 30 Oct 2024 02:23:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 382:
> 
>> 380:                  i, xmm[1], xmm[0]);
>> 381:   }
>> 382:   st->print("  MXCSR=" UINT32_FORMAT_X_0, uc->MxCsr);
> 
> Is this moved from somewhere else?

No, it was added in `master`. You are looking at a merge commit. (I usually don't merge in master in an ongoing PR but in this case there was a conflict so I had to resolve it.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822345558

From ihse at openjdk.org  Wed Oct 30 10:45:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 10:45:16 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
 <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>
Message-ID: <eOYIXtGbSZdwTEG2t93ICRJPWWDltpJfW7h_H-QBGGU=.29a2b636-99ab-4ef1-9770-aacec2e0158d@github.com>

On Wed, 30 Oct 2024 02:18:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes. As Julian says, it's something we set up in our builds:
>> 
>>   if test "x$FLAGS_CPU_BITS" = x64; then
>>     $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
>>     $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
>>   fi
>
> Ugghh! I was thrown by the `x` in test expressions and thought `x64` meant, well, x64 :)

Yeah, that idiom is indeed difficult to read. :-(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822342078

From ihse at openjdk.org  Wed Oct 30 11:08:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:08:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>

On Tue, 29 Oct 2024 23:48:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> make/scripts/compare.sh line 79:
> 
>> 77: 
>> 78: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>> 79:   DIS_DIFF_FILTER="$SED -r \
> 
> This is now being defined for windows-aarch64 too, when it previously wasn't.  Is that intentional?

No, it was not intentional, as in I forgot about the aarch64 version of Windows.

With that said, I think it still might make sense to keep it this way. I don't think anyone has ever tried running the compare script on windows-aarch64; if they had, the lack of a filter at all would have made it basically unusable. This pattern is trying to hide 64-bit hex strings, and it is reasonable to assume it will work for aarch64 as well. If it doesn't, then its better to use this as a starting point for tweaking. Good catch, though!

> make/scripts/compare.sh line 1457:
> 
>> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
> 
> This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
> given the "x64" suffix.

Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. 

I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822382796
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822386222

From ihse at openjdk.org  Wed Oct 30 11:13:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:13:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v14]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <KvUQC6EJEWrUs-hTd1RUv54Tks7naEdUavPtMPlqNJM=.b2c52593-7ccd-4de0-b508-2086aed554cf@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore comment on calling conventions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/3556bec5..341de0b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=12-13

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Wed Oct 30 11:13:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:13:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v12]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <xM8E_uqyfL5bpnC-q9WX2ddV61gdjiRvMAIIX1ssgCo=.26e776dc-85ef-4594-a916-55d22a06739b@github.com>

On Wed, 30 Oct 2024 00:07:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adlc need _CRT_NONSTDC_NO_WARNINGS as well... *sigh*
>
> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1433:
> 
>> 1431: 
>> 1432:   int stack_size = stack_slots * VMRegImpl::stack_slot_size;
>> 1433: 
> 
> I think it might be better to keep this comment.  It might be helpful information for someone who
> needs to touch this code between now and when we remove all 32bit x86 support (which might
> be soonish, but not immediate).  And this comment will go away when that change happens.

Ok. 

Many of these changes were made in the jdk-sandbox before the JEP to deprecate all 32-bit x86 code was created, and in that perspective, it made more sense to actually properly clean out the Windows things from the x86 code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822396126

From ihse at openjdk.org  Wed Oct 30 11:18:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:18:27 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Error in os_windows.cpp for unknown cpu

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/341de0b2..0fff0971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=13-14

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Wed Oct 30 11:23:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:23:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>

On Wed, 30 Oct 2024 03:05:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Error in os_windows.cpp for unknown cpu
>
> src/hotspot/share/adlc/main.cpp line 494:
> 
>> 492: }
>> 493: 
>> 494: #if !defined(_WIN32) || defined(_WIN64)
> 
> Removing the conditionalization is fine for this change.  But see also 
> https://bugs.openjdk.org/browse/JDK-8342639
> I've added a note there that this change removed the conditionalization.

I'm glad you're giving some TLC to adlc. It is in desperate need of it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822410201

From ihse at openjdk.org  Wed Oct 30 11:23:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:23:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
 <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>
Message-ID: <tF_hM8P2ePWwvhpQtU4hQxAQsIRAQiBckplGKAoniXI=.c5767e49-0861-4615-8562-168800258573@github.com>

On Wed, 30 Oct 2024 03:13:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It's something we do in our build. For us, _LP64 really means 64 bit
>
> It seems like the `_WIN64` check here was never useful.  It's also been there since before the
> mercurial age.

The "mercurial age". Sounds like something in-between the stone age and the bronze age. :-D

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822412706

From ihse at openjdk.org  Wed Oct 30 11:31:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:31:17 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <4vEbuSNfUF3Dvk1-qqvtbP8Xz73VvbYxA0uPO5b1Kuo=.01762c04-f070-4eb4-a059-6481c720e56c@github.com>

On Wed, 30 Oct 2024 03:24:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Error in os_windows.cpp for unknown cpu
>
> src/java.base/windows/native/libjava/gdefs_md.h line 31:
> 
>> 29: 
>> 30: #include <stddef.h>
>> 31: #ifndef _WIN64
> 
> I suspect the unix/windows gdefs_md.h files could be eliminated, and just make gdefs.h use portable
> headers.  That can be done as a separate cleanup.

Good point. I created https://bugs.openjdk.org/browse/JDK-8343291.

> src/java.base/windows/native/libjava/jlong_md.h line 66:
> 
>> 64: #define jlong_zero_init ((jlong) 0)
>> 65: 
>> 66: #ifdef _WIN64
> 
> After this change I think the differences between the unix and windows variants of this file are trivial
> and could be resolved in favor of moving everything directly into jlong.h.  Though note there are some
> places in java.desktop that currently directly include jlong_md.h.  This can be done as a separate cleanup.

Right. I updated JDK-8343291 to cover this case as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822420044
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822422712

From shade at openjdk.org  Wed Oct 30 12:14:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 12:14:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

I am basically okay with this PR. Only a few leftover comments.

make/hotspot/gensrc/GensrcAdlc.gmk line 50:

> 48:     ADLC_CFLAGS := -nologo -EHsc
> 49:     ADLC_CFLAGS_WARNINGS := -W3 -D_CRT_SECURE_NO_WARNINGS \
> 50:          -D_CRT_DECLARE_NONSTDC_NAMES -D_CRT_NONSTDC_NO_WARNINGS

Not clear why do we need these new warnings? I don't right away see anything in ADLC that needs it.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2404648390
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822494914

From shade at openjdk.org  Wed Oct 30 12:14:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 12:14:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
Message-ID: <zBuS5aHaQ4o7a7N3Bb0uP9VdMjtR2Ud9ZxpPZpr2JSs=.69a88e5b-a23a-40ef-b6f3-7e24940b8f7b@github.com>

On Wed, 30 Oct 2024 11:05:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/scripts/compare.sh line 1457:
>> 
>>> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>>> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>>> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
>> 
>> This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
>> given the "x64" suffix.
>
> Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. 
> 
> I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...).

So then previously we would go for `jgss-windows-i586-bin.zip` on Windows/AArch64, which also does not seem good. Seeing how there are no bug reports about this, I think we are fine with doing this cleanup, and dealing with the bug, if any, later. @magicus, please submit a JBS issue for it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822489074

From jwaters at openjdk.org  Wed Oct 30 12:33:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Oct 2024 12:33:28 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
Message-ID: <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>

On Wed, 30 Oct 2024 11:19:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/adlc/main.cpp line 494:
>> 
>>> 492: }
>>> 493: 
>>> 494: #if !defined(_WIN32) || defined(_WIN64)
>> 
>> Removing the conditionalization is fine for this change.  But see also 
>> https://bugs.openjdk.org/browse/JDK-8342639
>> I've added a note there that this change removed the conditionalization.
>
> I'm glad you're giving some TLC to adlc. It is in desperate need of it.

TLC?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822524730

From ihse at openjdk.org  Wed Oct 30 13:29:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 13:29:16 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
 <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>
Message-ID: <l4vK22batFEVTwXl2Nwi4xqhAKWF2r_TMMIA8xUKYmE=.98fc0abf-1e13-44b1-b729-3bdba414de62@github.com>

On Wed, 30 Oct 2024 12:30:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm glad you're giving some TLC to adlc. It is in desperate need of it.
>
> TLC?

https://www.vocabulary.com/dictionary/TLC

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822628499

From ihse at openjdk.org  Wed Oct 30 13:37:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 13:37:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>
Message-ID: <okuSQWnzbiRApfgxb9Ew56rztuYqWhzpMn3SAbnhDmE=.54c17b87-2b9a-466d-a3d4-10758c24dd33@github.com>

On Wed, 30 Oct 2024 12:11:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> make/hotspot/gensrc/GensrcAdlc.gmk line 50:
> 
>> 48:     ADLC_CFLAGS := -nologo -EHsc
>> 49:     ADLC_CFLAGS_WARNINGS := -W3 -D_CRT_SECURE_NO_WARNINGS \
>> 50:          -D_CRT_DECLARE_NONSTDC_NAMES -D_CRT_NONSTDC_NO_WARNINGS
> 
> Not clear why do we need these new warnings? I don't right away see anything in ADLC that needs it.

David Holmes [pointed out](https://github.com/openjdk/jdk/pull/21744#discussion_r1820429621) a chunk of old Windows definitions in `adlc.hpp`. I removed it, including the `_strdpup` define, to align with how the rest of Hotspot handles this peculiarity in Visual Studio, but that required adding the two special defines.

That change is arguably outside the scope of this PR. If you object to it, I can revert it and we'll handle that cleanup separately. It's sometimes hard to know where to stop when you start pulling on strings in old bad code and piece after piece of old legacy junk unravels.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822651205

From coleenp at openjdk.org  Wed Oct 30 17:26:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 17:26:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <48pRdCvEIvlz_mE1k0RcbMe5g41IwSakYibr8zzc13E=.ccfb704e-f5de-4cfa-b6c2-6fc4e76d58b6@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/oops/stackChunkOop.inline.hpp line 189:

> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const {
> 188:   ObjectWaiter* waiter = object_waiter();
> 189:   if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) {

Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; }

Not sure what this is excluding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425

From kvn at openjdk.org  Wed Oct 30 19:28:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:28:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <X7DL3g4Y1-HUMBoX2v0xWzSe_ydqOJHAboDro1I0alA=.b3502a5a-224e-4aae-a955-a6f1f62805f2@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

There is useless code in `src/hotspot/cpu//x86/interpreterRT_x86_32.cpp` which is guarded by `#ifdef AMD64` which is false for 32-bit.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2406069434

From mullan at openjdk.org  Wed Oct 30 19:28:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:28:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Modify three RMI tests to work without the security manager:
    - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
    - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
    - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
   Also remove them from the problem list.
 - Remove two obsolete RMI tests:
    - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
    - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
   Adjust two tests to run without the Security Manager:
    - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
    - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
   Remove all of these tests from the problem list.
 - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
 - Added API Notes to ProtectionDomain clarifying that the current policy always
   grants no permissions. A few other small changes to Policy and PD.
 - Merge branch 'master' into jep486
 - JAXP tests: organize imports of a few tests
 - Improve description of Executors.privilegedThreadFactory
 - rename TestAppletLoggerContext.java as suggested in util test review
 - clientlibs: Javadoc cleanup
 - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=05
  Stats: 68829 lines in 1886 files changed: 2485 ins; 62501 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From kvn at openjdk.org  Wed Oct 30 19:36:33 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:36:33 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <M7euyT-eOyKa6wBKIdzfewGt_uT99-HGPeOSHXtcHPE=.f16fb74e-57ae-4c99-a147-0b90b25ede6e@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

There are several combinations of `#ifdef _WINDOWS / #ifdef _LP64` in `src/hotspot//cpu/x86/vm_version_x86.cpp` and may be other places: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L515

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448187637

From coleenp at openjdk.org  Wed Oct 30 19:38:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 19:38:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

I've traced through the runtime code (minus calculations for continuations) and found some typos on the way.  Excellent piece of work.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:

> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
> 2234:       if (!mon_acquired) {
> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.

typo: acquire

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:

> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.

typo: can be walked

src/hotspot/share/runtime/javaThread.hpp line 334:

> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback

typo: Monitor **for** pending_contended_entered callback

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823233359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373

From coleenp at openjdk.org  Wed Oct 30 19:38:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 19:38:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
Message-ID: <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>

On Tue, 29 Oct 2024 23:16:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
> 
>> 1409:     // zero out fields (but not the stack)
>> 1410:     const size_t hs = oopDesc::header_size();
>> 1411:     oopDesc::set_klass_gap(mem, 0);
> 
> Why, bug fix or cleanup?

This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312

From kvn at openjdk.org  Wed Oct 30 19:40:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:40:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

Bug in `macroAssembler_x86.cpp` - should be `_WINDOWS`

src/hotspot//cpu/x86/macroAssembler_x86.cpp:#ifndef WINDOWS
src/hotspot//cpu/x86/macroAssembler_x86.cpp:#if defined(WINDOWS) && defined(_LP64)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448195812

From kvn at openjdk.org  Wed Oct 30 19:44:34 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:44:34 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <KSWNrkuRf4_G_XIRkBtf4TxRj73DMQxNGdsQLzNIA58=.5bda552c-c29d-4d35-9e1c-961f14e28f33@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

We may remove next code too: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compilerDefinitions.cpp#L563

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448203927

From mullan at openjdk.org  Wed Oct 30 19:46:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:46:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <lZcOTgw-GDnWydfumYS8_S_FKYztRvpJUdExxx0_pu4=.ef9178a6-ae67-40df-875d-d69968e75324@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Main changes in latest update include:

- Resolution of 6 remaining RMI related tests on the ProblemList by removing or replacing SM dependencies
- Added several API Notes to the `ProtectionDomain` to note that the "current policy" always grants no permissions.
- Updated definition of `networkaddress.cache.ttl` security property and removed specified behavior when Security Manager is enabled.
- Adjusted wording of `Executors.privilegedThreadFactory` and `privilegedCallable` to clarify use of current classloader
- A few miscellaneous fixes to tests, see other comments for pointer to fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448208886

From mullan at openjdk.org  Wed Oct 30 19:52:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:52:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
Message-ID: <WxVLgqtMTy2s4lu6__o0VRy59hAVkG7THNCACepN8Lk=.93d6e4e8-ad7a-451c-ac19-7593a3a95ec2@github.com>

On Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>> 
>>> 1611:      * interpreted as a {@code Font} object according to the
>>> 1612:      * specification of {@code Font.decode(String)}
>>> 1613:      * If the specified property is not found then null is returned instead.
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, null is returned instead.
>> 
>> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

>> src/java.desktop/share/classes/java/awt/Font.java line 1781:
>> 
>>> 1779:      * The property value should be one of the forms accepted by
>>> 1780:      * {@code Font.decode(String)}
>>> 1781:      * If the specified property is not found then the {@code font}
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, the {@code font}
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297079
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297577

From kvn at openjdk.org  Wed Oct 30 19:56:35 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:56:35 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

`grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448239347

From mullan at openjdk.org  Wed Oct 30 20:16:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <24vtAM0Ez1gNMgD69tDo3tvSJttBAB27n6S3du1YCI0=.3f968953-0bd9-4e8c-b77d-ef351f232116@github.com>

On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/376d1b58bd442143ed9dc48c7d38cb5535af1569

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448236942

From mullan at openjdk.org  Wed Oct 30 20:16:43 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
Message-ID: <GPn_TYX-s1iHAu2QRhyA6fZq0IY8QEj3151WQP3O44c=.5224e14c-d59c-4c01-a3cf-cf0a64bc998a@github.com>

On Mon, 28 Oct 2024 20:12:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around unnecessarily but otherwise looks fine.

JAXP test comments fixed in https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448243564

From pchilanomate at openjdk.org  Wed Oct 30 20:16:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Rename oopCont + fix in JvmtiUnmountBeginMark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/9fd4c036..63003d37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=18-19

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 20:16:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>
Message-ID: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.1dc24cd9-9de2-4fd3-8a38-def6dfe2dbda@github.com>

On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:
> 
>> 1080:     } else {
>> 1081:       assert(vthread != nullptr, "no vthread oop");
>> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);
> 
> Nit: The name `oopCont` does not match the HotSpot naming convention.
>        What about `cont_oop` or even better just `cont` as at the line 2550?

Renamed to cont.

> src/hotspot/share/prims/jvmtiExport.cpp line 1682:
> 
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
>> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));
> 
> I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

Right, good find. I missed `get_jvmti_thread_state ` will also create the state if null. How about this fix: https://github.com/pchilano/jdk/commit/baf30d92f79cc084824b207a199672f5b7f9be88
I now also see that JvmtiVirtualThreadEventMark tries to save some state of the JvmtiThreadState for the current thread before the callback, which is not the JvmtiThreadState of the vthread for this case. Don't know if something needs to change there too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449

From mullan at openjdk.org  Wed Oct 30 20:16:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
 <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
Message-ID: <eWQL7DYj1uuJ1CPxnHlGcggMuMiMzOOXFPDGrAbLQKM=.eb6e1333-eb8c-4d23-bca8-200a22e34ccd@github.com>

On Tue, 29 Oct 2024 18:35:05 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 392:
> 
>> 390:     /**
>> 391:      * Returns a thread factory used to create new threads that
>> 392:      * have current context class loader as the context class loader.
> 
> One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/06c4c3c1ab1fe121b625bd30a0c424be06d5022a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823307856

From pchilanomate at openjdk.org  Wed Oct 30 20:16:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
Message-ID: <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>

On Wed, 30 Oct 2024 09:44:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/share/runtime/continuation.cpp line 88:
> 
>> 86:       if (_target->has_async_exception_condition()) {
>> 87:         _failed = true;
>> 88:       }
> 
> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

> src/hotspot/share/runtime/continuation.cpp line 115:
> 
>> 113:       if (jvmti_present) {
>> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
>> 115:         if (JvmtiExport::should_post_vthread_mount()) {
> 
> This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
> Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

Fixed and added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891

From mullan at openjdk.org  Wed Oct 30 20:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <QDRmqh8JFZp8wqckrMDjRg-xZqTsqh2gMS35zax4RF4=.6f15599e-85ff-40aa-b736-b8f64074faa1@github.com>

On Fri, 25 Oct 2024 20:44:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:
> 
>> 38:  * @modules java.base/jdk.internal.access
>> 39:  *          java.logging
>> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet
> 
> Rename these?  What's really being tested, there are no more Applets.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/444fabe80a7b53ba208db99d69b9778a6113454d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823302577

From mullan at openjdk.org  Wed Oct 30 20:16:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
 <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
Message-ID: <GJqcqELAGDX0uDd55OOoblexMod-v5ByE02XvOpUx6M=.fb5f6f0b-66e8-4c47-b045-c99b5989df3e@github.com>

On Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>> 
>>> 1: /*
>> 
>> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?
>
> It can be removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b2d59a432d6472263c1706d9dbb83c99cbf79793

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823306809

From pchilanomate at openjdk.org  Wed Oct 30 20:16:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <ZELBjBKJitCg3vuMgSg_zsAmoOd6w3yxzlrWsHs8icg=.bd59eae1-ce5f-465a-b059-4ee8ca7a6f24@github.com>

On Mon, 21 Oct 2024 09:55:53 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename oopCont + fix in JvmtiUnmountBeginMark
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:
> 
>> 2536:   Method* m = hf.interpreter_frame_method();
>> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
>> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;
> 
> Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

I reverted this change and added an assert instead, since for native methods we always thaw the caller too, i.e. it will not be the bottom frame. I added a comment in the other two references for the extra native slots in continuationFreezeThaw_x86.inline.hpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839

From dholmes at openjdk.org  Wed Oct 30 21:10:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 21:10:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
 <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>
Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.939669fc-f0bc-49fc-8b00-3abe4beb846b@github.com>

On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.
>
> Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:
> 
> |                ThreadA                |                   ThreadB             |           ThreadC             |
> | --------------------------------------| --------------------------------------| ---------------------------------------------|
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
> |                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
> |                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
> |                                       | ExitEpilog:releases monitorB          |                                              |
> |                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
> |                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
> |                                       |                                       |     continues execution in Java              |
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
> |                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
> |  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
> |  ExitEpilog:releases monitorA         |                                       |                                              |
> |  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886

From dholmes at openjdk.org  Wed Oct 30 21:20:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 21:20:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>
Message-ID: <_feLyxFARa2bfW3YLKwRvzGE9Cmp8d-nWVUOo0uGa8g=.2fbee6c3-6339-461d-bfbb-2ffcbb507c22@github.com>

On Wed, 30 Oct 2024 20:16:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename oopCont + fix in JvmtiUnmountBeginMark

Updates look good - thanks.

I think I have nothing further in terms of the review process. Great work!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v21]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <hM7vyfAwIsZhjjsv0s4k4gzTzQhJCXE6qVDUfs2QpZk=.b71426d3-908f-449f-96f7-b86ff51d0c2f@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - SmallRegisterMap::instance() fix + comment typo
 - Add comment in call_VM_preemptable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/63003d37..aa682de2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=19-20

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
 <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
 <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>
Message-ID: <Go3eRJLPZ-G7dhFInCPSbRD-Zr7AtweuOE6jFZPX2Vw=.4ece3b76-0349-43fc-b79e-18c717d093bd@github.com>

On Tue, 29 Oct 2024 20:57:48 GMT, Dean Long <dlong at openjdk.org> wrote:

>> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.
>
> `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

I think aarch64 is the correct one. For interpreter frames we also have a sender_sp() that we get through that offset value: https://github.com/openjdk/jdk/blob/7404ddf24a162cff445cd0a26aec446461988bc8/src/hotspot/cpu/x86/frame_x86.cpp#L458
I think the confusion is because we also have interpreter_frame_sender_sp_offset where we store the unextended sp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>
Message-ID: <XzzSB-Dc6W-U5Iv31bsokNTokJFKCc_KY_7ylmRpMcs=.a9acc6bc-3132-42b4-bf34-a2743be5adc8@github.com>

On Wed, 30 Oct 2024 00:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:
> 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 360:   lea(rscratch1, resume_pc);
>> 361:   push(rscratch1);
> 
> Suggestion:
> 
>   push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

Added it as a note with the comment above.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:
> 
>> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
>> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
>> 2045:     // frame effectively overwritting the restored registers during that call.
> 
> Suggestion:
> 
>     // frame effectively overwriting the restored registers during that call.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823511520

From pchilanomate at openjdk.org  Wed Oct 30 22:18:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v21]
In-Reply-To: <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
Message-ID: <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>

On Wed, 30 Oct 2024 01:52:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - SmallRegisterMap::instance() fix + comment typo
>>  - Add comment in call_VM_preemptable
>
> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.PreemptStatus() in Continuation.java
> 
> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

`PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823509538

From pchilanomate at openjdk.org  Wed Oct 30 22:18:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>
Message-ID: <O0Q8Oqbznf66sDhuaExW_dXun9o3MO10gACNW1iUU5c=.e1d9350d-2653-43d5-8960-d8467df4090c@github.com>

On Tue, 29 Oct 2024 23:05:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:
> 
>> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
>> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
>> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;
> 
> `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

Maybe, but I only see it twice, not sure we gain much. Also we save having to jump back and forth to see what total_cont_size() would actually account for.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:
> 
>> 1061:   unwind_frames();
>> 1062: 
>> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);
> 
> It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

The reason why this is added and later subtracted is because when allocating the stackChunk we need to account for all space needed, but when specifying how much space the vthread needs in the stack to allocate the frames we don't need to count _monitors_in_lockstack. I'd rather not group it with frame::metadata_words because these are logically different things. In fact, if we never subtract frame::metadata_words when setting max_thawing_size we should not need to account for it in thaw_size() (this is probably something we should clean up in the future). But for _monitors_in_lockstack we always need to subtract it to max_thawing_size.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:
> 
>> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
>> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
>> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)
> 
> So this means it's OK to over-estimate the size here?

Yes, this will be the space allocated in the stack by the vthread when thawing.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:
> 
>> 2060:   }
>> 2061: 
>> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);
> 
> Suggestion:
> 
>   f.next(SmallRegisterMap::instance(), true /* stop */);
> 
> This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:
> 
>> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
>> 2649:   } else {
>> 2650:     _stream.next(SmallRegisterMap::instance);
> 
> Suggestion:
> 
>     _stream.next(SmallRegisterMap::instance());

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823486049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823487296
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823488795
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636

From pchilanomate at openjdk.org  Wed Oct 30 22:44:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:44:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos in comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/aa682de2..0951dfe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=20-21

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From dlong at openjdk.org  Wed Oct 30 23:05:48 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:05:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
 <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
Message-ID: <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>

On Tue, 29 Oct 2024 22:15:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1302:
>> 
>>> 1300:     _compiler_type           = type;
>>> 1301:     _orig_pc_offset          = 0;
>>> 1302:     _num_stack_arg_slots     = 0;
>> 
>> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.
>
> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138

From pchilanomate at openjdk.org  Wed Oct 30 23:17:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 23:17:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
 <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
Message-ID: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>

On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
>> 
>>> 1409:     // zero out fields (but not the stack)
>>> 1410:     const size_t hs = oopDesc::header_size();
>>> 1411:     oopDesc::set_klass_gap(mem, 0);
>> 
>> Why, bug fix or cleanup?
>
> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580273

From dlong at openjdk.org  Wed Oct 30 23:17:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:17:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <gAguZ8-ByDjb8T7nqwPQp3yYwXtckYDHXq3GnO33Rl8=.f2f95768-d8e6-415f-8cba-b0aebd3a9ea6@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/objectMonitor.cpp line 1612:

> 1610: 
> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.

I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051

From dlong at openjdk.org  Wed Oct 30 23:25:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:25:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
 <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
Message-ID: <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>

On Wed, 30 Oct 2024 22:11:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.hpp line 50:
>> 
>>> 48: class JavaThread;
>>> 49: 
>>> 50: // should match Continuation.PreemptStatus() in Continuation.java
>> 
>> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.
>
> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

Yes, that would be better for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967

From pchilanomate at openjdk.org  Wed Oct 30 23:25:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 23:25:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>
Message-ID: <wiVrOwnsnXq1emrHePR9UMImJfRkHBhQPqjBzda9f4M=.cb038fea-540d-4e8d-884e-ac34cc4973d1@github.com>

On Wed, 30 Oct 2024 19:06:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:
> 
>> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
>> 2234:       if (!mon_acquired) {
>> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.
> 
> typo: acquire

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:
> 
>> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
>> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
>> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> typo: can be walked

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 334:
> 
>> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
>> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
>> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback
> 
> typo: Monitor **for** pending_contended_entered callback

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583906
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583954
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583822

From dlong at openjdk.org  Thu Oct 31 00:54:51 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 00:54:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:

> 187: 
> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));

If these accesses need to be atomic, could you add a comment explaining why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621

From dlong at openjdk.org  Thu Oct 31 01:01:53 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 01:01:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <FWssbuS1i62rs41m2kBR4A6kHiudXckVxVI6u6v91oM=.b3b499a5-fbe8-4939-8513-c9e58423582e@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/deoptimization.cpp line 125:

> 123: 
> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
> 125:   if (!nm->can_be_deoptimized()) {

Is this a performance optimization?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339

From dlong at openjdk.org  Thu Oct 31 01:34:53 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 01:34:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:

> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
> 43:   int64_t tid = thread->lock_id();
> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Should the "3" be a named constant with a comment?

src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:

> 205: }
> 206: 
> 207: inline bool ObjectMonitor::has_successor() {

Why are _succ accesses atomic here when previously they were not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393

From dholmes at openjdk.org  Thu Oct 31 02:29:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:29:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>

On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
> 
>> 205: }
>> 206: 
>> 207: inline bool ObjectMonitor::has_successor() {
> 
> Why are _succ accesses atomic here when previously they were not?

General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823698001

From dlong at openjdk.org  Thu Oct 31 02:36:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 02:36:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
Message-ID: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>

On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
>> 
>> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.
>
> The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:
> 
> 
>    0xffffdfdba584:	sub	sp, sp, #0x10
>    0xffffdfdba588:	stp	x29, x30, [sp]
>    0xffffdfdba58c:	ldrb	w8, [x28, #1192]
>    0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
>    0xffffdfdba594:	mov	x8, #0x4ba0                	
>    0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
>    0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5a0:	mov	x0, x28
>    0xffffdfdba5a4:	blr	x8
>    0xffffdfdba5a8:	mov	x9, sp
>    0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
>    0xffffdfdba5b0:	mov	x0, x1
>    0xffffdfdba5b4:	mov	x1, x2
>    0xffffdfdba5b8:	mov	x2, x28
>    0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
>    0xffffdfdba5c0:	mov	x8, #0xe6a4                	
>    0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
>    0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
>    0xffffdfdba5d0:	blr	x8
>    0xffffdfdba5d4:	nop
>    0xffffdfdba5d8:	movk	xzr, #0x0
>    0xffffdfdba5dc:	movk	xzr, #0x0
>    0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
>    0xffffdfdba5e4:	str	xzr, [x28, #1000]
>    0xffffdfdba5e8:	str	xzr, [x28, #1008]
>    0xffffdfdba5ec:	ldr	x10, [x28, #8]
>    0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
>    0xffffdfdba5f4:	ldp	x29, x30, [sp]
>    0xffffdfdba5f8:	add	sp, sp, #0x10
>    0xffffdfdba5fc:	ret
>    0xffffdfdba600:	ldp	x29, x30, [sp]
>    0xffffdfdba604:	add	sp, sp, #0x10
>    0xffffdfdba608:	adrp	x8, 0xffffdfc30000
>    0xffffdfdba60c:	add	x8, x8, #0x80
>    0xffffdfdba610:	br	x8

OK, so you're saying it's the stack adjustment that's the problem.  It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary.  Isn't that a bug that should be fixed?  I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest.  Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling.

It's still unclear to me exactly how we resume after preemption.  It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted.  If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment.  In your example, last_Java_pc would be set to 0xffffdfdba5e4.  I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823701666

From dlong at openjdk.org  Thu Oct 31 03:55:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 03:55:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java.  Is there a way to fix that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446

From alanb at openjdk.org  Thu Oct 31 06:54:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 06:54:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>
Message-ID: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.cea2b3e3-caa3-4629-8bcc-82f33ae61971@github.com>

On Thu, 31 Oct 2024 03:52:31 GMT, Dean Long <dlong at openjdk.org> wrote:

> For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that?

I don't think which view this is but just to say that VirtualThreadPinnedEvent.java and libTracePinnedThreads.c are removed. libSynchronizedNative.c is part of a new test (as it happens, it was previously reviewed as pull/18600 but we had to hold it back as it needed a fix from the loom repo that is part of the JEP 491 implementation). You find is easier to just fetch and checkout the branch to look at the changes locally. Personally I have this easier for large change and makes it easier to see renames and/or removals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774

From sspitsyn at openjdk.org  Thu Oct 31 09:25:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Oct 2024 09:25:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
 <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>
Message-ID: <FKZnn7aT8nPcZxjsPU2a96efMUA2BkOBGXQhZ4KIlR4=.bbb34e06-c0ac-4544-986f-ca2680fed2e1@github.com>

On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 88:
>> 
>>> 86:       if (_target->has_async_exception_condition()) {
>>> 87:         _failed = true;
>>> 88:       }
>> 
>> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.
>
> These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

Just wanted to understand what needs to be checked after the start_VTMS_transition() call.
You are right, we need to check the `_thread->has_async_exception_condition()` after the call.
The pending `popframe` and  `earlyret` can be checked before as I understand.
I'm not sure there is a real need in double-checking before and after. So, let's keep it as it is for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824134075

From rriggs at openjdk.org  Thu Oct 31 15:58:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Oct 2024 15:58:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <y-jccaVTuCdisVPbN2qCr2rVn8tCHNLThqd75t2crl0=.7c7a4790-5327-4925-9153-e591cfee552d@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408378244

From mchung at openjdk.org  Thu Oct 31 16:11:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Oct 2024 16:11:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <T5ERS9U-Z-8BFoRNUpGqJnmRkP6FQc8DEX7qbXqODVU=.6f3e8f2f-de82-48c0-a8ee-c935093e825a@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408431117

From fbredberg at openjdk.org  Thu Oct 31 16:18:57 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 16:18:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.1b330f87-a4d3-4b20-b6ac-1aa45a5a19b5@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

Been learning a ton by reading the code changes and questions/answers from/to others.
But I still have some questions (and some small suggestions).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418

From fbredberg at openjdk.org  Thu Oct 31 16:18:59 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 16:18:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:

> 943: 
> 944:   void inc_held_monitor_count();
> 945:   void dec_held_monitor_count();

I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 

Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:

> 738: void MacroAssembler::clobber_nonvolatile_registers() {
> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
> 740:   Register regs[] = {

Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
Suggestion:

  static const Register regs[] = {

src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:

> 271:         ? frame_sp + fsize - frame::sender_sp_offset
> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
> 273:         : *(intptr_t**)(hf.sp() - 2);

Suggestion:

        : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:

> 791: 
> 792:   void inc_held_monitor_count(Register tmp = t0);
> 793:   void dec_held_monitor_count(Register tmp = t0);

I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/share/runtime/continuation.cpp line 125:

> 123: };
> 124: 
> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
Suggestion:

static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.cpp line 135:

> 133: #endif // INCLUDE_JVMTI
> 134: 
> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread`.
Suggestion:

static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.hpp line 66:

> 64: 
> 65:   enum preempt_kind {
> 66:     freeze_on_monitorenter = 1,

Is there a reason why the first enumerator doesn't start at zero?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:

> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
> 888:   } else {
> 889:     return freeze_pinned_native;

Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

src/hotspot/share/runtime/objectMonitor.cpp line 1193:

> 1191:   }
> 1192: 
> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");

In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822551094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822696920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822200193
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822537887
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824253403
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824255622
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824262945
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824405820
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824676122

From pchilanomate at openjdk.org  Thu Oct 31 16:27:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:27:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v23]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <xv2amcWDXc_uGB2S2DZoiWZbJ3qppSMtkrAmJCNZtd0=.402be468-c406-4fd1-a7c9-cedbb6b53e7a@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add ObjectMonitor::successor() method + use ThreadIdentifier::initial()
 - Comments for Dean

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0951dfe0..9f086c52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=21-22

  Stats: 13 lines in 5 files changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Thu Oct 31 16:38:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
 <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
 <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>
Message-ID: <DyT3JlQrGtqeWtycBFv1OKjZmtAyW3nw2G0_AGrx-s8=.1985fddd-fa5f-4c43-9b11-3adb18b4e6a9@github.com>

On Wed, 30 Oct 2024 23:02:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.
>
> Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565

From pchilanomate at openjdk.org  Thu Oct 31 16:38:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v23]
In-Reply-To: <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
 <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
 <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>
Message-ID: <RyqfC0X-r4X4nNHdq40aKJr0RnQyUR9Qcuckmcrcpc8=.380fcc65-f9b7-4d81-99ad-3187d2f612cd@github.com>

On Wed, 30 Oct 2024 23:22:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.
>
> Yes, that would be better for now.

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898

From pchilanomate at openjdk.org  Thu Oct 31 16:38:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
Message-ID: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>

On Thu, 31 Oct 2024 02:33:30 GMT, Dean Long <dlong at openjdk.org> wrote:

> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>
It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824782389

From pchilanomate at openjdk.org  Thu Oct 31 16:38:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>
Message-ID: <sIrGvDJcWMOXud3JGT-dpBAZ6CVMn6zp7tkTct0qay0=.91d48ee7-25d3-46ba-ae54-cae692f6096a@github.com>

On Thu, 31 Oct 2024 00:52:02 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:
> 
>> 187: 
>> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
>> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));
> 
> If these accesses need to be atomic, could you add a comment explaining why?

It is read concurrently by GC threads. Added comment.

> src/hotspot/share/runtime/deoptimization.cpp line 125:
> 
>> 123: 
>> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
>> 125:   if (!nm->can_be_deoptimized()) {
> 
> Is this a performance optimization?

No, this might be a leftover. When working on the change for Object.wait I was looking at the deopt code and thought this check was missing. It seems most callers already filter this case except WB_DeoptimizeMethod.

> src/hotspot/share/runtime/objectMonitor.cpp line 1612:
> 
>> 1610: 
>> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
>> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
> I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

The virtual thread is inside the thaw call here which is a leaf VM method, so there is no anchor. It is still in the mount transition before thawing frames. The top frame is Continuation.enterSpecial so that's what we set the anchor to.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:
> 
>> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
>> 43:   int64_t tid = thread->lock_id();
>> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Should the "3" be a named constant with a comment?

Yes, changed to use ThreadIdentifier::initial().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824792648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793200
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824791832
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793737

From pchilanomate at openjdk.org  Thu Oct 31 16:38:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
 <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>
Message-ID: <jY7WaK5NmmdDNXECTw7ByGpZ-QFceabiNhX5fucWL_E=.5854a481-b975-43d8-b49b-8c4f41a816cc@github.com>

On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.
>
>> Why are _succ accesses atomic here when previously they were not?
>>
> They should had always been atomic.

> But I agree it seems odd when direct accesses to _succ in the main cpp file are not atomic.
>
There was only one remaining direct access in debugging function `print_debug_style_on` which I fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794795

From pchilanomate at openjdk.org  Thu Oct 31 16:38:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
Message-ID: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>

On Thu, 31 Oct 2024 02:26:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
>> 
>>> 205: }
>>> 206: 
>>> 207: inline bool ObjectMonitor::has_successor() {
>> 
>> Why are _succ accesses atomic here when previously they were not?
>
> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

> Why are _succ accesses atomic here when previously they were not?
>
They should had always been atomic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794270

From dlong at openjdk.org  Thu Oct 31 19:11:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:11:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <p0EL5sSXDA_lCNzjlh-_wA7MtNlF7wyKjQdldfSaogY=.6a8b3970-8fdf-45dd-bff6-bdb6fbd2ab75@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/vframe.cpp line 289:

> 287:       current >= f.interpreter_frame_monitor_end();
> 288:       current = f.previous_monitor_in_interpreter_frame(current)) {
> 289:       oop owner = !heap_frame ? current->obj() : StackValue::create_stack_value_from_oop_location(stack_chunk(), (void*)current->obj_adr())->get_obj()();

It looks like we don't really need the StackValue.  We might want to make it possible to call oop_from_oop_location() directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757

From dlong at openjdk.org  Thu Oct 31 19:16:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:16:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/vframe.inline.hpp line 130:

> 128:       // Waited event after target vthread was preempted. Since all continuation frames
> 129:       // are freezed we get the top frame from the stackChunk instead.
> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);

What happens if we don't do this?  That might help explain why we are doing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976

From dlong at openjdk.org  Thu Oct 31 19:20:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:20:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <vVmCo-n8F4TL2Si5e7S5oTlZf3BCOYzVwyvQgC42ewU=.46d8f3eb-9721-46f2-98f8-a1e6dcd22df0@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:         }

Please explain why it is safe to remvoe the above code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769

From pchilanomate at openjdk.org  Thu Oct 31 20:02:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 20:02:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v24]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <V6WytPJ_bdxusndeknCz0Rh4NyaZhG1YlOWKCV9A_Es=.f72d1ae9-7d24-4217-a5d1-3c7f86a97dc1@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Remove redundant assert in ObjectMonitor::VThreadEpilog
 - Comment in FreezeBase::recurse_freeze + renames in continuation.hpp
 - Explicitly pass tmp register to inc/dec_held_monitor_count + use static const in clobber_nonvolatile_registers
 - Use frame::sender_sp_offset in continuationFreezeThaw_riscv.inline.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/9f086c52..aa263f56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=22-23

  Stats: 43 lines in 16 files changed: 2 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From dlong at openjdk.org  Thu Oct 31 20:02:49 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 20:02:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:

> 55:     static {
> 56:         try {
> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);

Why is this needed?  A comment would help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245

From pchilanomate at openjdk.org  Thu Oct 31 20:20:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 20:20:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
Message-ID: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>

On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:
> 
>> 943: 
>> 944:   void inc_held_monitor_count();
>> 945:   void dec_held_monitor_count();
> 
> I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 
> 
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:
> 
>> 738: void MacroAssembler::clobber_nonvolatile_registers() {
>> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
>> 740:   Register regs[] = {
> 
> Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
> Suggestion:
> 
>   static const Register regs[] = {

Added.

> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
> 
>> 271:         ? frame_sp + fsize - frame::sender_sp_offset
>> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
>> 273:         : *(intptr_t**)(hf.sp() - 2);
> 
> Suggestion:
> 
>         : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

Changed.

> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:
> 
>> 791: 
>> 792:   void inc_held_monitor_count(Register tmp = t0);
>> 793:   void dec_held_monitor_count(Register tmp = t0);
> 
> I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/share/runtime/continuation.cpp line 125:
> 
>> 123: };
>> 124: 
>> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt_for_jvmti.

> src/hotspot/share/runtime/continuation.cpp line 135:
> 
>> 133: #endif // INCLUDE_JVMTI
>> 134: 
>> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt, which I think it reads even better.

> src/hotspot/share/runtime/continuation.hpp line 66:
> 
>> 64: 
>> 65:   enum preempt_kind {
>> 66:     freeze_on_monitorenter = 1,
> 
> Is there a reason why the first enumerator doesn't start at zero?

There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:
> 
>> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
>> 888:   } else {
>> 889:     return freeze_pinned_native;
> 
> Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

We just found a frame that can't be freezed, most likely the call_stub or upcall_stub which indicate there are further natives frames up the stack. I added a comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1193:
> 
>> 1191:   }
>> 1192: 
>> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");
> 
> In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

The `guarantee` tries to mimic the one here: https://github.com/openjdk/jdk/blob/ae82cc1ba101f6c566278f79a2e94bd1d1dd9efe/src/hotspot/share/runtime/objectMonitor.cpp#L1613
The assert at the epilogue is probably redundant. Also in `UnlinkAfterAcquire`, the else branch already asserts `ObjectWaiter::TS_CXQ`. I removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101744
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825108078
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825100526
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101246
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107036
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825102359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825103008
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825106368

From dlong at openjdk.org  Thu Oct 31 20:20:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 20:20:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:

> 106:         processDeregisterQueue();
> 107: 
> 108:         if (Thread.currentThread().isVirtual()) {

It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

test/hotspot/gtest/nmt/test_vmatree.cpp line 34:

> 32: 
> 33: using Tree = VMATree;
> 34: using TNode = Tree::TreapNode;

Why is this needed?

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:

> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos

I'm guessing these changes have something to do with JDK-8279653?

test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:

> 71: /* ========================================================================== */
> 72: 
> 73: static int prepare(JNIEnv* jni) {

Is this a bug fix?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825109698
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107638

From alanb at openjdk.org  Thu Oct 31 20:20:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:20:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
Message-ID: <RtT7q4CD6pe5qYxQQCHybX2wyJ4UQONkL6OSDjiBAVo=.e6bfc819-297a-41fb-bf72-e33f4e6434e6@github.com>

On Thu, 31 Oct 2024 20:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:
> 
>> 106:         processDeregisterQueue();
>> 107: 
>> 108:         if (Thread.currentThread().isVirtual()) {
> 
> It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

When executed on a platform thread is will block in epoll_wait or kqueue so it has to handle EINTR. It doesn't block in sys call when executed in a virtual thread. So very different implementations.

> test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:
> 
>> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
>> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
>> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos
> 
> I'm guessing these changes have something to do with JDK-8279653?

It should have been added when Thread.sleep was changed but we got lucky.

> test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:
> 
>> 71: /* ========================================================================== */
>> 72: 
>> 73: static int prepare(JNIEnv* jni) {
> 
> Is this a bug fix?

Testing ran into a couple of bugs in JVMTI tests. One of was tests that was stashing the JNIEnv into a static.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254

From alanb at openjdk.org  Thu Oct 31 20:26:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:26:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
Message-ID: <7hUuYlCwm3busYFnC5Z0Iq7bv8204h26-nAfOBnIStU=.4e387823-c30e-45a4-889c-fbe9ffffca30@github.com>

On Thu, 31 Oct 2024 20:12:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> test/hotspot/gtest/nmt/test_vmatree.cpp line 34:
> 
>> 32: 
>> 33: using Tree = VMATree;
>> 34: using TNode = Tree::TreapNode;
> 
> Why is this needed?

We had to rename the alias to avoid a compiling with the Node in compile.hpp. Just lucky not to run into this in main-line. I think Johan had planned to change this in main line but it may have got forgotten.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520

From alanb at openjdk.org  Thu Oct 31 20:30:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:30:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>
Message-ID: <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@github.com>

On Thu, 31 Oct 2024 19:59:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:
> 
>> 55:     static {
>> 56:         try {
>> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
> 
> Why is this needed?  A comment would help.

That's probably a good idea.  It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591

From fbredberg at openjdk.org  Thu Oct 31 21:14:51 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 21:14:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
Message-ID: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>

On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.hpp line 66:
>> 
>>> 64: 
>>> 65:   enum preempt_kind {
>>> 66:     freeze_on_monitorenter = 1,
>> 
>> Is there a reason why the first enumerator doesn't start at zero?
>
> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825168519

From pchilanomate at openjdk.org  Thu Oct 31 21:50:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:50:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - add comment to ThreadService::find_deadlocks_at_safepoint
 - Remove assignments in preempt_kind enum

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/aa263f56..e5a9ce2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=23-24

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Thu Oct 31 21:50:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:50:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>
Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.c2ffa35e-fe62-4f3e-a3ae-b01c19a924b7@github.com>

On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.
>
> Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

Yes, I missed to include it in the previous changes. I actually removed the assignment altogether since there is no need to rely on particular values (although it will start at zero by default).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825202651

From pchilanomate at openjdk.org  Thu Oct 31 21:54:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:54:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>
Message-ID: <tq9aHsQgDVjbvosLzR6tYM3Gs4-sblUlfXeLdnw_WuM=.b5a8125f-85bd-4017-ac2a-2bbdffc39153@github.com>

On Thu, 31 Oct 2024 19:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/vframe.inline.hpp line 130:
> 
>> 128:       // Waited event after target vthread was preempted. Since all continuation frames
>> 129:       // are freezed we get the top frame from the stackChunk instead.
>> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);
> 
> What happens if we don't do this?  That might help explain why we are doing this.

We would walk the carrier thread frames instead of the vthread ones.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:         }
> 
> Please explain why it is safe to remvoe the above code.

Yes, I should have added a comment here. The previous code assumed that if the monitor had an owner but it was not findable it meant the previous currentThread will be blocked permanently and so we recorded this as a deadlock. With these changes, the owner could be not findable because it is an unmounted vthread. There is currently no fast way to determine if that's the case so we never record this as a deadlock. Now, unless there is a bug in the VM, or a thread exits without releasing monitors acquired through JNI, unfindable owner should imply an unmounted vthread. I added a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260