From dholmes at openjdk.org  Fri Nov  1 01:59:50 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Nov 2024 01:59:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
Message-ID: <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>

On Thu, 31 Oct 2024 21:50:50 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 comment to ThreadService::find_deadlocks_at_safepoint
>  - Remove assignments in preempt_kind enum

Marked as reviewed by dholmes (Reviewer).

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:     // frame can't be freezed. Most likely the call_stub or upcall_stub

Suggestion:

    // Frame can't be frozen. Most likely the call_stub or upcall_stub

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:           // If currentThread is nullptr we would like to know if the owner

Suggestion:

          // If currentThread is null we would like to know if the owner

src/hotspot/share/services/threadService.cpp line 474:

> 472:           // vthread we never record this as a deadlock. Note: unless there
> 473:           // is a bug in the VM, or a thread exits without releasing monitors
> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.

Suggestion:

          // acquired through JNI, null should imply an unmounted vthread owner.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446

From dlong at openjdk.org  Fri Nov  1 07:17:48 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 07:17:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@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>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
Message-ID: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo <pchilanomate 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?  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.
>
>> 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.

It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409

From attila at openjdk.org  Fri Nov  1 09:19:12 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Fri, 1 Nov 2024 09:19:12 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: <yCCKheohe-gTYgtLgXobFgKSQOYjymWCWQ_0zzF9O0w=.84ce1a1f-f8ca-435b-8a98-63073ac9ea5a@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

`jdk.dynalink` changes look good.

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

Marked as reviewed by attila (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2409755977

From aboldtch at openjdk.org  Fri Nov  1 15:26:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 1 Nov 2024 15:26:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
Message-ID: <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>

On Thu, 31 Oct 2024 21:50:50 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 comment to ThreadService::find_deadlocks_at_safepoint
>  - Remove assignments in preempt_kind enum

src/hotspot/share/oops/stackChunkOop.cpp line 445:

> 443: 
> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();

Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 

There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

src/hotspot/share/oops/stackChunkOop.cpp line 460:

> 458:     } else {
> 459:       oop value = *reinterpret_cast<oop*>(at);
> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);

Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254

From ihse at openjdk.org  Fri Nov  1 15:46:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:46:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v16]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <X-W5xpLJavtod2GFKfnRm8CDWgjcpiJde9NDq00JIcU=.b88eb238-28a6-4bb1-a7dc-5c07f920a295@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:

  No need to check for LP64 inside a #ifdef _WINDOWS anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/0fff0971..fe8ba082

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

  Stats: 8 lines in 1 file changed: 0 ins; 8 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  Fri Nov  1 15:46:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:46:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
Message-ID: <ZvX86_z9vXhkAYeLLm_uj2RwRvsii-DdQgffQc6Smk4=.0a8ca866-0f7e-4df5-b217-1a55228f313e@github.com>

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov <kvn 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
>
> `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

@vnkozlov 

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

Yes; this has been discussed above. Aleksey opened https://bugs.openjdk.org/browse/JDK-8343167 to solve that separately, since it is not Windows 32-bit specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452093887

From ihse at openjdk.org  Fri Nov  1 15:55:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:55:39 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
Message-ID: <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>

On Wed, 30 Oct 2024 19:37:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Bug in macroAssembler_x86.cpp - should be _WINDOWS

So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452112264

From ihse at openjdk.org  Fri Nov  1 16:04:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:04:55 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
Message-ID: <Y585KrkQYx3x1yODXG7iY--AYSguo2hiH-7X8rLet-Y=.9627af5f-b665-4259-8483-35bb1c7ec9e4@github.com>

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

I'm actually not sure which places you refer to here. Can you be more specific? 

(Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452127151

From ihse at openjdk.org  Fri Nov  1 16:04:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:04:55 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@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 superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
 - Remove windows-32-bit code in CompilerConfig::ergo_initialize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fe8ba082..68d6fe5a

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

  Stats: 7 lines in 2 files 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 bpb at openjdk.org  Fri Nov  1 16:31:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Nov 2024 16:31:46 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt [v2]
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: <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>

> Move LimitDirectMemory to the problem list which best matches the observed failure mode.

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

 - 8343234: Add aarch64 to allowed arch of LimitDirectMemory
 - 8343234: Add java/nio/Buffer/LimitDirectMemory.java to ProblemList-Virtual.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21773/files
  - new: https://git.openjdk.org/jdk/pull/21773/files/b45d5864..6e08f82e

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

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 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  Fri Nov  1 16:31:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Nov 2024 16:31:46 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt
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: <6532cgw_1uGcEPUnnEZbD8QLYcc_1jHi2jwPA87y-Bo=.3eed0d52-f973-4153-9d81-0475786cda1b@github.com>

On Tue, 29 Oct 2024 21:31:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move LimitDirectMemory to the problem list which best matches the observed failure mode.

Commit 6e08f82 incidentally adds `aarch64` to the targeted architectures. Many repeats on these platforms have shown no failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/21773#issuecomment-2452172352

From kvn at openjdk.org  Fri Nov  1 17:55:41 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 17:55:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
 <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>
Message-ID: <xX7oGwHEdEU6DdTfgEI9j5dePvA77d5amR3Hefjl6KQ=.cf304223-330d-49f2-b7ae-c1fb90b886f4@github.com>

On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Bug in macroAssembler_x86.cpp - should be _WINDOWS
> 
> So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal.

I think `WINDOWS` is not defined in our build macros. I filed https://bugs.openjdk.org/browse/JDK-8343452 to fix it and backport.

> > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes
> 
> I'm actually not sure which places you refer to here. Can you be more specific?
> 
> (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.)


% grep -i win32 -r src/hotspot/share/ 
src/hotspot/share//c1/c1_Compiler.cpp:  // compilation seems to be too expensive (at least on Intel win32).
src/hotspot/share//runtime/globals.hpp:          "Using high time resolution (for Win32 only)")                    \
src/hotspot/share//runtime/globals.hpp:          "Bypass Win32 file system criteria checks (Windows Only)")        \
src/hotspot/share//runtime/globals.hpp:          "Unguard page and retry on no-execute fault (Win32 only) "        \
src/hotspot/share//runtime/javaCalls.cpp:  // This is used for e.g. Win32 structured exception handlers.
src/hotspot/share//runtime/safefetch.hpp:#ifdef _WIN32
src/hotspot/share//runtime/os.hpp:  class win32;
src/hotspot/share//runtime/vmStructs.cpp:  /* unsigned short on Win32 */                                           \
src/hotspot/share//runtime/vmStructs.cpp:  // Win32, we can put this back in.
src/hotspot/share//runtime/park.cpp:// Native TLS (Win32/Linux/Solaris) can only be initialized or
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:// by roughly 15% on both Win32/x86 and Solaris/SPARC.
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share//prims/jvmti.xml:      example, in the Java 2 SDK a CTRL-Break on Win32 and a CTRL-\ on Linux
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//classfile/javaClasses.cpp:#if defined(_WIN32) && !defined(_WIN64)
src/hotspot/share//classfile/compactHashtable.cpp:#ifndef O_BINARY       // if defined (Win32) use binary files.
src/hotspot/share//cds/filemap.cpp:#ifndef O_BINARY       // if defined (Win32) use binary files.
src/hotspot/share//utilities/vmError.cpp:#ifndef _WIN32
src/hotspot/share//adlc/adlc.hpp:#ifdef _WIN32
src/hotspot/share//adlc/adlc.hpp:#endif // _WIN32
src/hotspot/share//adlc/main.cpp:#if !defined(_WIN32) || defined(_WIN64)
src/hotspot/share//compiler/disassembler.cpp:#ifdef _WIN32

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452318589
PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452322471

From alanb at openjdk.org  Fri Nov  1 17:59:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Nov 2024 17:59:27 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt [v2]
In-Reply-To: <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
References: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
 <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
Message-ID: <UGyLIjc9WF0cngQ2dyiGDWMt8sqILNGqGkSPqQ7Wj5o=.fd7e3e0d-8155-4ad5-a5f9-f99e0dc7b974@github.com>

On Fri, 1 Nov 2024 16:31:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move LimitDirectMemory to the problem list which best matches the observed failure mode.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8343234: Add aarch64 to allowed arch of LimitDirectMemory
>  - 8343234: Add java/nio/Buffer/LimitDirectMemory.java to ProblemList-Virtual.txt

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21773#pullrequestreview-2410614567

From kvn at openjdk.org  Fri Nov  1 18:04:44 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 18:04:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <qof8GPRZ7SEfAZIx94XqCQX-yFCXy2A-ooZqLdsYV2k=.a62af9ab-1f10-4ce3-b8e0-7bf42baca07d@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

1. There is use of `WIN32` instead of `_WIN32`.
2. There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion.
3. There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE.
4. "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452335968

From kvn at openjdk.org  Fri Nov  1 18:13:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 18:13:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Okay, I am confuse about `_WIN32` vs `WIN32`. 

You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32`
And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452349567

From pchilanomate at openjdk.org  Fri Nov  1 18:19:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:19:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v26]
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: <glhsL1_7cEL9eimWvI0jzYJZFcbSdVW0KiikTxvVNW4=.06978271-02cd-4fb1-91b6-042687b606d3@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 with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Fix comments for David
 - Add comment in X509TrustManagerImpl.java
 - Remove oop clearing in transfer_lockstack + pass _barriers as argument
 - Merge branch 'master' into JDK-8338383
 - add comment to ThreadService::find_deadlocks_at_safepoint
 - Remove assignments in preempt_kind enum
 - 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
 - ... and 51 more: https://git.openjdk.org/jdk/compare/751a914b...113fb3d3

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

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25
  Stats: 9506 lines in 242 files changed: 6936 ins; 1424 del; 1146 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 Nov  1 18:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
 <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>
Message-ID: <xQ12-EqaObKFPZllXD9_E3Wcb0nf4oEEGFwab-AoYPg=.9cf2aa52-cd1f-4d70-86e3-ccaced3421a8@github.com>

On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/oops/stackChunkOop.cpp line 445:
> 
>> 443: 
>> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
>> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> 
> Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 
> 
> There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

Good, passed as argument now.

> src/hotspot/share/oops/stackChunkOop.cpp line 460:
> 
>> 458:     } else {
>> 459:       oop value = *reinterpret_cast<oop*>(at);
>> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> 
> Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
> So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

Ok, I just omitted clearing the oop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888

From pchilanomate at openjdk.org  Fri Nov  1 18:24:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:24:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
 <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>
Message-ID: <f4ZgITHm9pgiBkVpXqBXvnlwcG0H0v_uB4jrxo-jsCw=.e29b33d5-46a4-4886-ab08-41b57be1bacc@github.com>

On Fri, 1 Nov 2024 01:53:01 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 comment to ThreadService::find_deadlocks_at_safepoint
>>  - Remove assignments in preempt_kind enum
>
> 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:     // frame can't be freezed. Most likely the call_stub or upcall_stub
> 
> Suggestion:
> 
>     // Frame can't be frozen. Most likely the call_stub or upcall_stub

Fixed.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:           // If currentThread is nullptr we would like to know if the owner
> 
> Suggestion:
> 
>           // If currentThread is null we would like to know if the owner

Fixed.

> src/hotspot/share/services/threadService.cpp line 474:
> 
>> 472:           // vthread we never record this as a deadlock. Note: unless there
>> 473:           // is a bug in the VM, or a thread exits without releasing monitors
>> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.
> 
> Suggestion:
> 
>           // acquired through JNI, null should imply an unmounted vthread owner.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815

From pchilanomate at openjdk.org  Fri Nov  1 18:24:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:24:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@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>
 <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@github.com>
Message-ID: <cbf7sd9t-JRpuKIcvoZXbga78_Uwu_mqHYxoto2prGs=.40966aac-9897-4568-8019-4e46115f8a1d@github.com>

On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

Added comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929

From pchilanomate at openjdk.org  Fri Nov  1 18:29:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:29:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@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>
 <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@github.com>
Message-ID: <eQsNuW1dYTC5Jth_rKACj76kGFv3ShNY0hP525XOIM8=.8d6d5d7e-0a48-43a2-9caa-a8b2a684e3a7@github.com>

On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

Brought the comment from the loom repo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691

From prr at openjdk.org  Fri Nov  1 18:46:57 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Nov 2024 18:46:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

make/modules/jdk.accessibility/Lib.gmk line 57:

> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
> 56: 
> 57:   ##############################################################################

Most of the desktop related changes are related to Assistive Technologies
I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.

So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826177047

From pchilanomate at openjdk.org  Fri Nov  1 18:47:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:47:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v27]
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: <CZQmDqaeoz76pMRNejHdpcbTg-o_PTENxGtTxVYHpGg=.6995864d-89ad-4f82-a011-b0ca2c8e0f72@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:

  Revert fixes after 8343132

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/113fb3d3..33eb6388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25-26

  Stats: 22 lines in 3 files changed: 0 ins; 17 del; 5 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 aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 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: <5_m66jOr6E-qHq5r9AHGX-Yb5IKCT_VbHGmq_Yh8v34=.172e81bb-9281-4364-a8cb-3696c5ef4b36@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

I looked through the updates to `java.desktop` module and to tests under `java/awt`, `javax/sound`, `javax/swing`.

Looks good.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2410517684

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@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>
 <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>
Message-ID: <mvT1t92RTxP5hIzw4FI8nhFlY_Vv9Md6ZhT5I6jr4rc=.16f5be4b-3885-4e52-920f-7cf399e99a70@github.com>

On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @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.

> > 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_.
>
> ? 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.

I've submitted [JDK-8343448](https://bugs.openjdk.org/browse/JDK-8343448): _Improve formatting of docs in java.awt.Desktop_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826079117

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@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>
 <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>
Message-ID: <BKKnlgdcwUbIGvmukmS0xfXL3JqXL6TVXwckzzdXKRk=.c68053bd-cb29-4dcc-a34b-c0a49397ff6c@github.com>

On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

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

I've submitted [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446): _Add missing periods in docs for java.awt.Font_.

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

Deferred to [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826080609
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826081342

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
Message-ID: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>

On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

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

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

@prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?

The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:

https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826141057

From pchilanomate at openjdk.org  Fri Nov  1 19:37:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 19:37:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
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: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@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:

  Use lazySubmitRunContinuation when blocking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/33eb6388..52c26642

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26-27

  Stats: 3 lines in 1 file 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 aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 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: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@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

test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:

> 1: /*

I wonder if we should add an Oracle copyright to the update test file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826228675

From aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@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>
 <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>
Message-ID: <f5IcQJqOak2nDS4qB6f3s_Dl-zHGs4g45Grph8KCe_s=.9978557c-258f-4b7f-b49a-c0595cfd2a29@github.com>

On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

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

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826225216

From dlong at openjdk.org  Fri Nov  1 20:11:50 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 20:11:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@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>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
Message-ID: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>

On Fri, 1 Nov 2024 07:14:35 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.
>
> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

Here's my suggested C2 change:

diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
index d9c77a2f529..1e99db191ae 100644
--- a/src/hotspot/cpu/aarch64/aarch64.ad
+++ b/src/hotspot/cpu/aarch64/aarch64.ad
@@ -3692,14 +3692,13 @@ encode %{
       __ post_call_nop();
     } else {
       Label retaddr;
+      // Make the anchor frame walkable
       __ adr(rscratch2, retaddr);
+      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
       __ lea(rscratch1, RuntimeAddress(entry));
-      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
-      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
       __ blr(rscratch1);
       __ bind(retaddr);
       __ post_call_nop();
-      __ add(sp, sp, 2 * wordSize);
     }
     if (Compile::current()->max_vector_size() > 0) {
       __ reinitialize_ptrue();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551

From dlong at openjdk.org  Fri Nov  1 20:30:51 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 20:30:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.b0547cc1-5c22-4b3f-9fe2-fb57c8ef326b@github.com>

On Fri, 1 Nov 2024 19:37: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 one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

Marked as reviewed by dlong (Reviewer).

I finished looking at this, and it looks good.  Nice work!

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349

From aivanov at openjdk.org  Fri Nov  1 20:31:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 20:31:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@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>
 <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>
Message-ID: <sA2jKaSsQXz3NGMICFq-okZkJV_NNcIPZgEyd-vEMio=.bcb93df4-b266-4951-87d4-a91d610ec051@github.com>

On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

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

> 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 " 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.

I guess it's the intended behaviour, jtreg implies `@run` if there are no other commands; you have to provide `@run` explicitly if there are `@compile` or `@build` tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826256418

From fbredberg at openjdk.org  Fri Nov  1 20:59:49 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 1 Nov 2024 20:59:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <ssUtNAUgdYvjQ_KecwfpxDRYGOfUMmTx_05x9S0U58o=.f78a1d08-115d-4027-8e8d-14552092d31d@github.com>

On Fri, 1 Nov 2024 19:37: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 one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks!

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086

From kbarrett at openjdk.org  Fri Nov  1 22:10:40 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 1 Nov 2024 22:10:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <0AP1wOF-MdqLdSNofINZ2JTL4nnIdVFRsZpZ1LT7oHY=.e1bb41e9-b0f4-4157-9d78-d5b819c5c1d9@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Looks good, subject to addressing @vnkozlov comments.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2410940653

From fyang at openjdk.org  Sat Nov  2 02:44:55 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 2 Nov 2024 02:44:55 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: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>

On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713

From sspitsyn at openjdk.org  Sat Nov  2 04:53:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Nov 2024 04:53:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <a4feDci916h0jQyvBcTdBCTt_Cn20rkNi8pm2TuEkbw=.5babb895-54e3-4427-be3d-3e87b5943b8a@github.com>

On Fri, 1 Nov 2024 19:37: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 one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/hotspot/share/runtime/objectMonitor.cpp line 537:

> 535:       }
> 536:     }
> 537: 

Just a question. It is not clear from scratch why the `Continuation::try_preempt()` is called before the `VThreadMonitorEnter()`. It would be nice to add a comment explaining it. It can be also good to explain how it works together in this order. Even a surface explanation of a general idea would be very helpful. A part of this already explained in the comment at lines 515-517.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826492850

From kizune at openjdk.org  Sat Nov  2 07:53:44 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 2 Nov 2024 07:53:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
Message-ID: <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>

On Fri, 1 Nov 2024 18:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> make/modules/jdk.accessibility/Lib.gmk line 57:
> 
>> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>> 56: 
>> 57:   ##############################################################################
> 
> Most of the desktop related changes are related to Assistive Technologies
> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.
> 
> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java

We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826520980

From jpai at openjdk.org  Sat Nov  2 10:24:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Nov 2024 10:24:33 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt [v2]
In-Reply-To: <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
References: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
 <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
Message-ID: <pj0Y33y-DxDKKUcRZR4n0hAfm8Ta2IrPX_rgstjREqs=.a563e6ad-fc47-48c2-813d-601996b4daa7@github.com>

On Fri, 1 Nov 2024 16:31:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Move LimitDirectMemory to the problem list which best matches the observed failure mode.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8343234: Add aarch64 to allowed arch of LimitDirectMemory
>  - 8343234: Add java/nio/Buffer/LimitDirectMemory.java to ProblemList-Virtual.txt

The change looks reasonable to me. I've added an inline comment about the `@requires` in the test. I don't have a strong preference about it and it's OK if you want to continue using it in the proposed form.

test/jdk/java/nio/Buffer/LimitDirectMemory.java line 28:

> 26:  * @bug 4627316 6743526
> 27:  * @summary Test option to limit direct memory allocation
> 28:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")

Hello Brian, this seems to cover all the platforms that mainline currently supports. So I'm not sure if the `@requires` is anymore needed. I couldn't find the historical context on why that `@requires` was added in the first place.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21773#pullrequestreview-2411228561
PR Review Comment: https://git.openjdk.org/jdk/pull/21773#discussion_r1826541339

From jpai at openjdk.org  Sat Nov  2 10:29:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Nov 2024 10:29:29 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt [v2]
In-Reply-To: <pj0Y33y-DxDKKUcRZR4n0hAfm8Ta2IrPX_rgstjREqs=.a563e6ad-fc47-48c2-813d-601996b4daa7@github.com>
References: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
 <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
 <pj0Y33y-DxDKKUcRZR4n0hAfm8Ta2IrPX_rgstjREqs=.a563e6ad-fc47-48c2-813d-601996b4daa7@github.com>
Message-ID: <Qc2TLSPiaGD5_b3G-epayTrEYi8l92bexvEas55vWvI=.436edc1f-53ac-49aa-98be-59a0f1473ea5@github.com>

On Sat, 2 Nov 2024 10:20:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8343234: Add aarch64 to allowed arch of LimitDirectMemory
>>  - 8343234: Add java/nio/Buffer/LimitDirectMemory.java to ProblemList-Virtual.txt
>
> test/jdk/java/nio/Buffer/LimitDirectMemory.java line 28:
> 
>> 26:  * @bug 4627316 6743526
>> 27:  * @summary Test option to limit direct memory allocation
>> 28:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")
> 
> Hello Brian, this seems to cover all the platforms that mainline currently supports. So I'm not sure if the `@requires` is anymore needed. I couldn't find the historical context on why that `@requires` was added in the first place.

Never mind, I just realized that I hadn't taken into account other architectures like `riscv64`, `ppc64le` and similar. Although this test might still pass there, I think it's reasonable to continue to use the `@requires` like you have done here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21773#discussion_r1826542330

From acobbs at openjdk.org  Sat Nov  2 16:24:58 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 16:24:58 GMT
Subject: RFR: 8343484: Remove unnecessary @SuppressWarnings annotations (nio)
Message-ID: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>

Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

Commit messages:
 - Remove unnecessary @SuppressWarnings annotations.

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

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

From duke at openjdk.org  Sat Nov  2 22:42:07 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 2 Nov 2024 22:42:07 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: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@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

src/java.base/share/classes/java/lang/System.java line 1364:

> 1362:      * <br>
> 1363:      * It is the responsibility of the provider of
> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that

This is?still a?part of?the?paragraph related to?the?security?manager.

src/java.base/share/classes/java/lang/System.java line 2338:

> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
> 2338:      *    negatively with custom security managers and custom class loaders

They?might?still interact?negatively with?custom class?loaders?though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826864120
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826863295

From acobbs at openjdk.org  Sun Nov  3 03:11:42 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 3 Nov 2024 03:11:42 GMT
Subject: RFR: 8343484: Remove unnecessary @SuppressWarnings annotations
 (nio) [v2]
In-Reply-To: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
References: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
Message-ID: <RyteIoLkc5lqxREQiNnTTxcvBdu0lImEE6ftGeGfFas=.91992dda-cdab-4080-a4fd-0693f181092b@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-nio
 - Merge branch 'master' into SuppressWarningsCleanup-nio
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21858/files
  - new: https://git.openjdk.org/jdk/pull/21858/files/5b5fd5f1..6b79f798

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

  Stats: 3225 lines in 123 files changed: 2078 ins; 749 del; 398 mod
  Patch: https://git.openjdk.org/jdk/pull/21858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21858/head:pull/21858

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

From alanb at openjdk.org  Sun Nov  3 07:01:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 07:01:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <ZlkjUPtWJiKV28QHg5wypFJPAkqECKNofd8X0Tr6TqA=.8ffd4d6f-3d9b-4978-a45c-804050b038ba@github.com>

On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss <duke 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 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
>
> src/java.base/share/classes/java/lang/System.java line 2338:
> 
>> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
>> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
>> 2338:      *    negatively with custom security managers and custom class loaders
> 
> They?might?still interact?negatively with?custom class?loaders?though.

The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876

From alanb at openjdk.org  Sun Nov  3 07:40:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 07:40:28 GMT
Subject: RFR: 8343484: Remove unnecessary @SuppressWarnings annotations
 (nio) [v2]
In-Reply-To: <RyteIoLkc5lqxREQiNnTTxcvBdu0lImEE6ftGeGfFas=.91992dda-cdab-4080-a4fd-0693f181092b@github.com>
References: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
 <RyteIoLkc5lqxREQiNnTTxcvBdu0lImEE6ftGeGfFas=.91992dda-cdab-4080-a4fd-0693f181092b@github.com>
Message-ID: <nch9ZB95geZF1m8eqKm_BbYY5YFPem9x_ZOuM8fJixw=.02471f9a-7cdb-4ba0-8876-0549a02e5c9a@github.com>

On Sun, 3 Nov 2024 03:11:42 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-nio
>  - Merge branch 'master' into SuppressWarningsCleanup-nio
>  - Remove unnecessary @SuppressWarnings annotations.

This looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21858#pullrequestreview-2411795593

From dfuchs at openjdk.org  Sun Nov  3 11:28:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sun, 3 Nov 2024 11:28:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>

On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss <duke 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 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
>
> src/java.base/share/classes/java/lang/System.java line 1364:
> 
>> 1362:      * <br>
>> 1363:      * It is the responsibility of the provider of
>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
> 
> This is?still a?part of?the?paragraph related to?the?security?manager.

Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826959976

From alanb at openjdk.org  Sun Nov  3 12:36:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 12:36:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
Message-ID: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>

On Sun, 3 Nov 2024 11:25:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 1364:
>> 
>>> 1362:      * <br>
>>> 1363:      * It is the responsibility of the provider of
>>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
>> 
>> This is?still a?part of?the?paragraph related to?the?security?manager.
>
> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826972198

From dholmes at openjdk.org  Mon Nov  4 02:18:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 02:18:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>

On Fri, 1 Nov 2024 19:37: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 one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/hotspot/share/classfile/javaClasses.cpp line 2107:

> 2105: 
> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
> 2107:   return vthread->long_field(_timeout_offset);

Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518

From dholmes at openjdk.org  Mon Nov  4 02:37:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 02:37:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Changes requested by dholmes (Reviewer).

src/hotspot/share/adlc/adlc.hpp line 43:

> 41: 
> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
> 43: #ifdef _WIN32

As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412031267
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827135809

From alanb at openjdk.org  Mon Nov  4 05:54:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 05:54:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>

On Mon, 4 Nov 2024 02:12: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:
>> 
>>   Use lazySubmitRunContinuation when blocking
>
> src/hotspot/share/classfile/javaClasses.cpp line 2107:
> 
>> 2105: 
>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>> 2107:   return vthread->long_field(_timeout_offset);
> 
> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720

From aboldtch at openjdk.org  Mon Nov  4 07:23:51 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 4 Nov 2024 07:23:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>

On Fri, 1 Nov 2024 19:37: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 one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:

> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
> 61:         MONITOR(3, "Monitor held"),
> 62:         CRITICAL_SECTION(4, "In critical section");

Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 

I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764

From alanb at openjdk.org  Mon Nov  4 08:02:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 08:02:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>
Message-ID: <BkN1BsPeLLAq5jaNhuPg6jhdvE5gOtPxRWJFlcHI06s=.b0ef271e-eb4e-4bad-a5d6-da42fb6186f6@github.com>

On Mon, 4 Nov 2024 07:21:19 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:
>> 
>>   Use lazySubmitRunContinuation when blocking
>
> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
> 
>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>> 61:         MONITOR(3, "Monitor held"),
>> 62:         CRITICAL_SECTION(4, "In critical section");
> 
> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
> 
> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.

Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145

From kbarrett at openjdk.org  Mon Nov  4 09:03:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 4 Nov 2024 09:03:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
Message-ID: <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>

On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> src/hotspot/share/adlc/adlc.hpp line 43:
> 
>> 41: 
>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
>> 43: #ifdef _WIN32
> 
> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.

The deletion is apparently working, else we'd be getting build failures. So
while there are some potential issues and opportunities for further cleanup in
this file, I think they ought to be addressed separately from this PR. See
new https://bugs.openjdk.org/browse/JDK-8343530.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827395928

From dholmes at openjdk.org  Mon Nov  4 09:13:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 09:13:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
Message-ID: <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>

On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/adlc/adlc.hpp line 43:
>> 
>>> 41: 
>>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
>>> 43: #ifdef _WIN32
>> 
>> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.
>
> The deletion is apparently working, else we'd be getting build failures. So
> while there are some potential issues and opportunities for further cleanup in
> this file, I think they ought to be addressed separately from this PR. See
> new https://bugs.openjdk.org/browse/JDK-8343530.

There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827408129

From stuefe at openjdk.org  Mon Nov  4 09:24:58 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:24:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Can we get rid of `JNICALL` too, please? 

Or would that change be too big?

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454188077

From stefank at openjdk.org  Mon Nov  4 09:26:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 4 Nov 2024 09:26:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@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>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>
Message-ID: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@github.com>

On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

This code in `StackChunkAllocator::initialize` mimics the clearing code in:

void MemAllocator::mem_clear(HeapWord* mem) const {
  assert(mem != nullptr, "cannot initialize null object");
  const size_t hs = oopDesc::header_size();
  assert(_word_size >= hs, "unexpected object size");
  oopDesc::set_klass_gap(mem, 0);
  Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
}


but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:

  if (oopDesc::has_klass_gap()) {
    oopDesc::set_klass_gap(mem, 0);
  }


So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227

From alanb at openjdk.org  Mon Nov  4 09:31:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 09:31:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
Message-ID: <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>

On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can we get rid of `JNICALL` too, please?
> 
> Or would that change be too big?

There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454201348

From stuefe at openjdk.org  Mon Nov  4 09:44:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:44:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <S3to4nvu45BtZKorVzUHq4daKm1C0J9261npLggqSKY=.76940878-b961-4add-9e73-1db9cf1439b4@github.com>

On Fri, 1 Nov 2024 16:04:55 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 two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

This is a very nice reduction in complexity. As I wrote before, removing windows 32-bit removes the need for calling convention definition, so I think we could get rid of JNICALL in addition to anything stdcall/fastcall related.

I had a close look at hotspot os and os_cpu changes, cursory glances at other places, all looked fine.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412592195

From stuefe at openjdk.org  Mon Nov  4 09:47:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:47:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
Message-ID: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>

On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Can we get rid of `JNICALL` too, please?
> > Or would that change be too big?
> 
> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.

Yeah. I count >8000 places in total...

Maybe just define JNICALL to be empty in jni_md.h for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454234501

From kbarrett at openjdk.org  Mon Nov  4 10:01:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 4 Nov 2024 10:01:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
 <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
Message-ID: <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>

On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The deletion is apparently working, else we'd be getting build failures. So
>> while there are some potential issues and opportunities for further cleanup in
>> this file, I think they ought to be addressed separately from this PR. See
>> new https://bugs.openjdk.org/browse/JDK-8343530.
>
> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.

"using namespace std;" in a header is generally a bad idea. It brings all
kinds of stuff into scope, potentially leading to name conflicts down the
road.  And seems like a strange thing to do only for windows.

Removal of the strdup macro is covered by the NONSTDC macros added at build
time.  It's not a 32bit cleanup either, and you suggested it.

Removal of [u]intptr_t definitions will cause a build failure if it results in
them being undefined. And getting an incorrect definition from elsewhere seems
implausible. I claim this all just isn't needed anymore and can be removed in
this PR, just as you suggested for the strdup macro. The 64bit definitions
could be added back in this PR (to be removed later by JDK-8343530), but that
just seems like useless churn.

So I'm happy with the current removal of the entire chunk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827469354

From fbredberg at openjdk.org  Mon Nov  4 14:00:55 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 4 Nov 2024 14:00:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
Message-ID: <PEExBTpPubCYRqoBU8sHuhGn7KxgJhWaRkGXiAJ22zA=.20d2683e-a50e-43e4-bc66-12c14540b42c@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269

From ihse at openjdk.org  Mon Nov  4 16:42:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:42:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v20]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <l_31uZeJj8FS4Ru5W6OcQcMSD8OtSqWIipI-yoUWm_k=.8d78d54c-b9fb-40ed-968a-20c7660eb5e1@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 __stdcall notation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d89bc561..fbd91ad0

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

  Stats: 119 lines in 13 files changed: 0 ins; 1 del; 118 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 Nov  4 16:11:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:11:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
 <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>
Message-ID: <fmrIkRBDxIQLLWZkOB684A_agGnxeaOWiv-Eq6sTpBo=.c069a94b-1cb9-4bf9-b691-1bdd2b4ac65f@github.com>

On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Lib.gmk line 57:
>> 
>>> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>>> 56: 
>>> 57:   ##############################################################################
>> 
>> Most of the desktop related changes are related to Assistive Technologies
>> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
>> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.
>> 
>> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java
>
> We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll.

@azuev-java Thanks! I have one more question for you: To avoid risking breaking any compatibility, the file generated from the source code in `windowsaccessbridge` is still compiled into a file called `windowsaccessbridge-64.dll`.

This is a bit unusual, and requires a quirk in the build system -- normally we assume there is a 1-to-1 relationship between the directory containing the native library source code, and the generated `.dll` file.

Is this file exposed to external parties, that rely on a specific name? Or is it just used internally by the JDK, so we could rename it to `windowsaccessbridge.dll`, and just update our reference to it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827989703

From acobbs at openjdk.org  Mon Nov  4 16:17:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 4 Nov 2024 16:17:35 GMT
Subject: Integrated: 8343484: Remove unnecessary @SuppressWarnings annotations
 (nio)
In-Reply-To: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
References: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
Message-ID: <uvs-LexknBnQ5Zow4QpiVUsgo0RL0NWciHK1EJHzCnc=.360bfcbf-bf60-465b-a40c-04afa078de4d@github.com>

On Sat, 2 Nov 2024 16:19:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

This pull request has now been integrated.

Changeset: 23fa1a33
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23fa1a33274d279a53fa6dde683900450561957b
Stats:     5 lines in 3 files changed: 0 ins; 1 del; 4 mod

8343484: Remove unnecessary @SuppressWarnings annotations (nio)

Reviewed-by: alanb

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

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

From ihse at openjdk.org  Mon Nov  4 16:53:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:53:48 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
 <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
Message-ID: <dYqkU6p0odvrMTRmYgM5_sSENvyiy7OPTEeWaYps7FA=.5a641a0c-e65a-4ee3-ba35-1e54b76f4b06@github.com>

On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Can we get rid of `JNICALL` too, please?
>>> 
>>> Or would that change be too big?
>> 
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.
>
>> > Can we get rid of `JNICALL` too, please?
>> > Or would that change be too big?
>> 
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.
> 
> Yeah. I count >8000 places in total...
> 
> Maybe just define JNICALL to be empty in jni_md.h for now.

@tstuefe Your comment reminded me of another important cleanup, to remove `__stdcall` (and `_stdcall`, an accepted but not recommended variant) from the code base. This only has meaning on 32-bit Windows.

Furthermore, when searching for this, I found additional code that is looking for symbol names of "__stdcall format", i.e. `<name>@<number>`. This is not needed anymore. I'll delete it where I find it, but there might be other places that I'm missing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455215002

From acobbs at openjdk.org  Mon Nov  4 16:17:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 4 Nov 2024 16:17:35 GMT
Subject: RFR: 8343484: Remove unnecessary @SuppressWarnings annotations
 (nio) [v2]
In-Reply-To: <RyteIoLkc5lqxREQiNnTTxcvBdu0lImEE6ftGeGfFas=.91992dda-cdab-4080-a4fd-0693f181092b@github.com>
References: <wX0N5kGbNqBLbf9mLjjHiQ9VZmYhKIkOzTSAqn9QGkg=.e029e77e-3990-469e-b18c-16375c7509e3@github.com>
 <RyteIoLkc5lqxREQiNnTTxcvBdu0lImEE6ftGeGfFas=.91992dda-cdab-4080-a4fd-0693f181092b@github.com>
Message-ID: <l18X5eRaU1GBB6JlBWfcLISi52N015g8TzSiuwRjETU=.4702fe6d-bb3b-428e-9dc0-c015b81fe78f@github.com>

On Sun, 3 Nov 2024 03:11:42 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-nio
>  - Merge branch 'master' into SuppressWarningsCleanup-nio
>  - Remove unnecessary @SuppressWarnings annotations.

Argh!! `Charset-X-Coder.java.template` copyright header didn't get updated.

I will fix ASAP with a new issue & PR.

Thanks for the review in any case.

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

PR Comment: https://git.openjdk.org/jdk/pull/21858#issuecomment-2455131454

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v18]
In-Reply-To: <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
 <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
 <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>
Message-ID: <ne3jiyOsMfrRR78dRubq7XYN1IWPeB0yrRNaHfx32t8=.50e2fd0d-245b-4ba5-ac0b-788ad46a993b@github.com>

On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.
>
> "using namespace std;" in a header is generally a bad idea. It brings all
> kinds of stuff into scope, potentially leading to name conflicts down the
> road.  And seems like a strange thing to do only for windows.
> 
> Removal of the strdup macro is covered by the NONSTDC macros added at build
> time.  It's not a 32bit cleanup either, and you suggested it.
> 
> Removal of [u]intptr_t definitions will cause a build failure if it results in
> them being undefined. And getting an incorrect definition from elsewhere seems
> implausible. I claim this all just isn't needed anymore and can be removed in
> this PR, just as you suggested for the strdup macro. The 64bit definitions
> could be added back in this PR (to be removed later by JDK-8343530), but that
> just seems like useless churn.
> 
> So I'm happy with the current removal of the entire chunk.

It was already quite tangential to the 32-bit windows removal effort. I've restored the original code (with the exception of the 32-bit Windows part) in this PR, so we don't have to argue about that. 

Let's remove this as a separate effort, presumably as part of JDK-8343530.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828003651

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
 <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
Message-ID: <wusCVNALP98v4yha8evAdBZUokZY5sEhJ5Eo2zx8n70=.7ff6d430-0b29-4eb9-a89b-38fef3a933de@github.com>

On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can we get rid of `JNICALL` too, please?

That we can never do, since it is part of jni.h which are imported in likely millions of JNI projects. But we can replace it with an empty define. And we can document it as not needed anymore, and start removing it from our own call sites.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455142166

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v18]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <BnN2NNTPOoC5clxA5LEplx4qwv2F0N2o_szfhAzHH2U=.c4c53af3-659f-4c70-91f0-61f802a56536@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 code in adlc.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/68d6fe5a..c6dce38d

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

  Stats: 27 lines in 1 file changed: 27 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  Mon Nov  4 16:28:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:28:14 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v19]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <ry3di_toZWQQc2kWuGeEKSqjCZgcx4JnV6qdRSadSqA=.d3586b29-650d-41e2-bbc8-4a6ec16da688@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:

  Make JNICALL an empty define on all platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/c6dce38d..d89bc561

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

  Stats: 7 lines in 3 files changed: 2 ins; 3 del; 2 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 acobbs at openjdk.org  Mon Nov  4 16:26:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 4 Nov 2024 16:26:40 GMT
Subject: RFR: 8343551: Missing copyright header update in
 Charset-X-Coder.java.template
Message-ID: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>

Please review this trivial patch to fix a missed copyright header update in the fix for [JDK-8343484](https://bugs.openjdk.org/browse/JDK-8343551).

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

Commit messages:
 - Update copyright header after JDK-8343484.

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

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

From kvn at openjdk.org  Mon Nov  4 17:04:43 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:04:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
Message-ID: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>

On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?

Yes, I completely agree to do such clean up in separate RFE. Please, file one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455239110

From ihse at openjdk.org  Mon Nov  4 17:11:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:11:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
Message-ID: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>

On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
> 
> Yes, I completely agree to do such clean up in separate RFE. Please, file one.

Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455256779

From kvn at openjdk.org  Mon Nov  4 17:20:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:20:04 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
 <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
Message-ID: <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>

On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>> 
>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
>
>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>> 
>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
> 
> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.

@magicus
Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ?

I see only few uses of `#ifdef WIN32`  in HotSpot which can be replaced with `#ifdef _WINDOWS`:

src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32


Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455274589

From ihse at openjdk.org  Mon Nov  4 16:06:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:06:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
Message-ID: <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>

On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> Okay, I am confuse about `_WIN32` vs `WIN32`. 
> 
> You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32`
> And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470

@vnkozlov 

> * There is use of `WIN32` instead of `_WIN32`.
> 
> * There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion.
> 
> * There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE.
> 
> * "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that.

Ok. Let's start with being on the same page about the meaning of "win32". This is what Microsoft has to say about it:

"The Win32 API (also called the Windows API) is the native platform for Windows apps. [T]he same functions are generally supported on 32-bit and 64-bit Windows." 

https://learn.microsoft.com/en-us/windows/win32/apiindex/api-index-portal#win32-windows-api

I'd say that they are the authoritative source on the subject. :-)

So technically there is nothing **wrong** with stuff targeting Windows being called "win32", even if we only support 64-bit Windows going forward. 

With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?

I will, however, do an additional round of checking all the grep hits on "win32" left to double-and-triple check that they indeed are not 32-bit specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455104589

From iris at openjdk.org  Mon Nov  4 17:30:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 4 Nov 2024 17:30:31 GMT
Subject: RFR: 8343551: Missing copyright header update in
 Charset-X-Coder.java.template
In-Reply-To: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
References: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
Message-ID: <jPe-r84ZuB1bkcOIz-z6z_QOn5FriGddsJi3q5a-EtA=.f12ddff3-8fa9-412a-8cac-52370aa5f776@github.com>

On Mon, 4 Nov 2024 16:21:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this trivial patch to fix a missed copyright header update in the fix for [JDK-8343484](https://bugs.openjdk.org/browse/JDK-8343551).

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21882#pullrequestreview-2413680588

From ihse at openjdk.org  Mon Nov  4 17:31:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:31:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v21]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@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:

  Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fbd91ad0..dccf1a1d

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Nov  4 17:31:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:31:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
 <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
 <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>
Message-ID: <5af9UbiLlBKx6KCuroe94EZxYiD0d9jqmt6TSgYp4XM=.e1b42d0c-4d70-46c6-9e00-bc3e102bf9ec@github.com>

On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>>> 
>>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
>> 
>> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.
>
> @magicus
> Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ?
> 
> I see only few uses of `#ifdef WIN32`  in HotSpot which can be replaced with `#ifdef _WINDOWS`:
> 
> src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
> src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
> 
> 
> Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later.

@vnkozlov I have now looked at all ~1800 case-independent hits of "win32" in the `src` directory. All of them is referring to the general Windows API, and not any 32-bit specific code, as far as I can tell from the filename and local context.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455296938

From acobbs at openjdk.org  Mon Nov  4 17:49:28 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 4 Nov 2024 17:49:28 GMT
Subject: RFR: 8343551: Missing copyright header update in
 Charset-X-Coder.java.template
In-Reply-To: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
References: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
Message-ID: <P-2VsMq0gjXUH0GgPZwFCELQTn1Yiw1dIfTMLvBkwcg=.f1250db5-56cf-4eed-9e42-0932d09b9687@github.com>

On Mon, 4 Nov 2024 16:21:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this trivial patch to fix a missed copyright header update in the fix for [JDK-8343484](https://bugs.openjdk.org/browse/JDK-8343551).

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21882#issuecomment-2455308372

From acobbs at openjdk.org  Mon Nov  4 17:49:29 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 4 Nov 2024 17:49:29 GMT
Subject: Integrated: 8343551: Missing copyright header update in
 Charset-X-Coder.java.template
In-Reply-To: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
References: <QyQxBwvu-XesX4B9S_Al6_SLKvfa6IlZHwQwFS7cQtk=.88197f9e-ea01-4303-8462-8e1c2ea2628d@github.com>
Message-ID: <MvO-NTAwbBDNVquDyoGSoRJGQXEV-KGUwofbziPbIGg=.f8ca3741-cdf3-40a9-81b7-ca1758718854@github.com>

On Mon, 4 Nov 2024 16:21:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this trivial patch to fix a missed copyright header update in the fix for [JDK-8343484](https://bugs.openjdk.org/browse/JDK-8343551).

This pull request has now been integrated.

Changeset: 1cc3586c
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1cc3586c5328e7b792498707a08952e760b3511f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8343551: Missing copyright header update in Charset-X-Coder.java.template

Reviewed-by: iris

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

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

From kvn at openjdk.org  Mon Nov  4 17:49:43 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:49:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v21]
In-Reply-To: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com>
Message-ID: <UCODrURe99cINxVpVWuWvlF5pHBHbtUEMZNTi8fmHYY=.4c0f7994-cc3b-473b-8f2e-a7e320838813@github.com>

On Mon, 4 Nov 2024 17:31:00 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:
> 
>   Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp

HotSpot VM changes are good for me.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2413705033

From pchilanomate at openjdk.org  Mon Nov  4 18:18:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:18:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
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: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@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:

 - Update comment block in objectMonitor.cpp
 - Fix issue with unmounted virtual thread when dumping heap
 - Remove ThawBase::possibly_adjust_frame()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/52c26642..11396312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27-28

  Stats: 349 lines in 14 files changed: 219 ins; 101 del; 29 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 bpb at openjdk.org  Mon Nov  4 18:21:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Nov 2024 18:21:37 GMT
Subject: RFR: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt [v2]
In-Reply-To: <Qc2TLSPiaGD5_b3G-epayTrEYi8l92bexvEas55vWvI=.436edc1f-53ac-49aa-98be-59a0f1473ea5@github.com>
References: <h3EDi3PgfNspV7kdWZCy5EVUbTU9-Wsk9_ifK4m1knE=.14e1e4b4-e40c-4c7e-b71a-bfc7ab2cc567@github.com>
 <X7K_EnBBdw3hjCzLRzEZpMCPX9P3_5JK6wyO-vMdmA8=.1d8d6cbf-1eb4-4042-907d-5ed287eefea2@github.com>
 <pj0Y33y-DxDKKUcRZR4n0hAfm8Ta2IrPX_rgstjREqs=.a563e6ad-fc47-48c2-813d-601996b4daa7@github.com>
 <Qc2TLSPiaGD5_b3G-epayTrEYi8l92bexvEas55vWvI=.436edc1f-53ac-49aa-98be-59a0f1473ea5@github.com>
Message-ID: <EOUUjpjwEhKR8fLDqq-G_ZKQ-UNmcbYAPpjIsIOYFp4=.0869bb64-8b66-41d8-92b6-86857b8dbaeb@github.com>

On Sat, 2 Nov 2024 10:26:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/nio/Buffer/LimitDirectMemory.java line 28:
>> 
>>> 26:  * @bug 4627316 6743526
>>> 27:  * @summary Test option to limit direct memory allocation
>>> 28:  * @requires (os.arch == "x86_64") | (os.arch == "amd64") | (os.arch == "aarch64")
>> 
>> Hello Brian, this seems to cover all the platforms that mainline currently supports. So I'm not sure if the `@requires` is anymore needed. I couldn't find the historical context on why that `@requires` was added in the first place.
>
> Never mind, I just realized that I hadn't taken into account other architectures like `riscv64`, `ppc64le` and similar. Although this test might still pass there, I think it's reasonable to continue to use the `@requires` like you have done here.

Thanks, @jaikiran, for noticing this. I don't know the whole story about `@requires` here and this combination is tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21773#discussion_r1828184260

From bpb at openjdk.org  Mon Nov  4 18:21:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Nov 2024 18:21:39 GMT
Subject: Integrated: 8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java
 from ProblemList.txt to ProblemList-Virtual.txt
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: <28bEn0xaOANuBUOFTWX9bPm_jRGH4-TuYHN22_0cfik=.9c990e4d-7085-486a-9221-187aa29de673@github.com>

On Tue, 29 Oct 2024 21:31:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Move LimitDirectMemory to the problem list which best matches the observed failure mode.

This pull request has now been integrated.

Changeset: 0668e181
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0668e181c8234df3fab478748b88365510a7343f
Stats:     6 lines in 3 files changed: 3 ins; 2 del; 1 mod

8343234: (bf) Move java/nio/Buffer/LimitDirectMemory.java from ProblemList.txt to ProblemList-Virtual.txt

Reviewed-by: alanb, jpai

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

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

From pchilanomate at openjdk.org  Mon Nov  4 18:21:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:21:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@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>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
Message-ID: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>

On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.
>
> Here's my suggested C2 change:
> 
> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
> index d9c77a2f529..1e99db191ae 100644
> --- a/src/hotspot/cpu/aarch64/aarch64.ad
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
> @@ -3692,14 +3692,13 @@ encode %{
>        __ post_call_nop();
>      } else {
>        Label retaddr;
> +      // Make the anchor frame walkable
>        __ adr(rscratch2, retaddr);
> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>        __ lea(rscratch1, RuntimeAddress(entry));
> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>        __ blr(rscratch1);
>        __ bind(retaddr);
>        __ post_call_nop();
> -      __ add(sp, sp, 2 * wordSize);
>      }
>      if (Compile::current()->max_vector_size() > 0) {
>        __ reinitialize_ptrue();

Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
@RealFYang I made the equivalent change for riscv, could you verify it's okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069

From pchilanomate at openjdk.org  Mon Nov  4 18:21:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:21:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>
Message-ID: <TWEXqyc2FnVrOO5eN1HMJQvlW9EoSrPVA8KntfcJOa8=.52901d8f-526e-4236-8c36-82bcdac14584@github.com>

On Tue, 29 Oct 2024 22:58: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 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.

Added an overload method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178

From pchilanomate at openjdk.org  Mon Nov  4 18:28:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:57 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: <3ThzYwhF_zfOZCcLiTcQIYjPtA5mNuUYZLWjiH3zJGE=.a4c97906-8a38-4af9-9cee-2c26b1f35271@github.com>

On Fri, 25 Oct 2024 04:40:24 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 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

Updated comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851

From pchilanomate at openjdk.org  Mon Nov  4 18:28:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
Message-ID: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876

From pchilanomate at openjdk.org  Mon Nov  4 18:28:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
Message-ID: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>

On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
>> 
>> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)
>
> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>
I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725

From pchilanomate at openjdk.org  Mon Nov  4 18:36:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:36:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
Message-ID: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.cafd8577-6aeb-4d4e-beaf-bc2148f28783@github.com>

On Mon, 4 Nov 2024 18:18: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 three additional commits since the last revision:
> 
>  - Update comment block in objectMonitor.cpp
>  - Fix issue with unmounted virtual thread when dumping heap
>  - Remove ThawBase::possibly_adjust_frame()

I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391

From ihse at openjdk.org  Mon Nov  4 19:27:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:27:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v22]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@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:

 - Also remove __cdecl
 - Also remove __stdcall on tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/dccf1a1d..82fbc51e

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

  Stats: 31 lines in 13 files changed: 0 ins; 10 del; 21 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 bpb at openjdk.org  Mon Nov  4 19:35:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 4 Nov 2024 19:35:01 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses microsecond
 precision with NOFOLLOW_LINKS
Message-ID: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>

Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.

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

Commit messages:
 - 8343417: (fs) BasicFileAttributeView.setTimes uses microsecond precision with NOFOLLOW_LINKS

Changes: https://git.openjdk.org/jdk/pull/21886/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21886&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343417
  Stats: 134 lines in 4 files changed: 113 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21886.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21886/head:pull/21886

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

From ihse at openjdk.org  Mon Nov  4 19:35:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:35:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v22]
In-Reply-To: <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@github.com>
Message-ID: <z6snV3KAVf4l0V8WVmg-7j-iTvmOHPEc63xaMECNDAs=.d6e8e32a-eeb5-402a-a6b2-cb6f619b19ad@github.com>

On Mon, 4 Nov 2024 19:27:59 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 two additional commits since the last revision:
> 
>  - Also remove __cdecl
>  - Also remove __stdcall on tests

I created https://bugs.openjdk.org/browse/JDK-8343560 to track the possible removal of `JNICALL` in the JDK source. Ultimately, we need to decide if it is worth the churn, or if we should keep it "just in case" some future platform will require a special keyword in that location (utterly unlikely as it might seem). If we go ahead with it, there are additional "downstream" fixes that needs to go with it, I highlighted some in the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455537378

From ihse at openjdk.org  Mon Nov  4 19:45:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:45:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v23]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Dpblra5ruIoDlXQ3V4X9fuLO4FZze26zdZ3-VVbenQE=.8cf7fc72-c864-497a-b8cb-a0aa4f5996f8@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:

  Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/82fbc51e..b5a481db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21-22

  Stats: 2 lines in 1 file changed: 0 ins; 1 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  Mon Nov  4 19:58:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:58:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v24]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Ta0FXWyz21fb4BXFGpdid-OOz3Kpx2XGcgela6DPaVI=.890a9ca1-1c20-4212-8430-b64468a94819@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:

  buildJniFunctionName is now identical on Windows and Unix, so unify it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/b5a481db..466a1a7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22-23

  Stats: 48 lines in 4 files changed: 8 ins; 40 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  Mon Nov  4 20:02:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:02:32 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v25]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <iqs_Vw8IIhc7MIkMdLUctlY5D5giJ6CUb-W2bD-o2Ps=.52368e54-2e67-457f-ba81-8a37b3b72afe@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 build_agent_function_name to not handle "@"-stdcall style names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/466a1a7a..88d89e75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23-24

  Stats: 21 lines in 1 file changed: 3 ins; 16 del; 2 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 Nov  4 20:18:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:18:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v26]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <3ZIvKBKdzJvYU91TwQcAGKUlDENAC5D5VNUFjI8zQzA=.a81d7ec5-c2ba-4eb0-ba78-c94ef65c8e28@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:

  [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/88d89e75..6f690d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24-25

  Stats: 21 lines in 3 files changed: 7 ins; 14 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  Mon Nov  4 20:21:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:21:09 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v27]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <_PNwSCgsqsInETeof5O-P5dZUGus72uvmtcYomw1QII=.eb53d7ac-250c-40cc-9fb5-68d5d3b15dd6@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:

  JVM_EnqueueOperation do not need __stdcall name lookup anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/6f690d02..48d722bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25-26

  Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 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 Nov  4 20:23:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:23:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v28]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <-YUW42BZ3ZY4k5baNUWfHqBlItoEyoOsXOMPxp_mvyM=.e3f414f4-c1c5-40db-ab72-debeb41968f5@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 33 commits:

 - Merge branch 'master' into impl-JEP-479
 - JVM_EnqueueOperation do not need __stdcall name lookup anymore
 - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them
 - Fix build_agent_function_name to not handle "@"-stdcall style names
 - buildJniFunctionName is now identical on Windows and Unix, so unify it
 - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer
 - Also remove __cdecl
 - Also remove __stdcall on tests
 - Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp
 - Remove __stdcall notation
 - ... and 23 more: https://git.openjdk.org/jdk/compare/8b474971...699c641a

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

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27
  Stats: 1885 lines in 84 files changed: 86 ins; 1572 del; 227 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 Nov  4 20:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:29:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v29]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@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:

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/699c641a..40291b9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27-28

  Stats: 39 lines in 39 files changed: 0 ins; 0 del; 39 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 Nov  4 20:38:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:38:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v29]
In-Reply-To: <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@github.com>
Message-ID: <rWM3MMHA1xaK4YTqh9aD2xuAXsZx1xS68U9Je4vTAls=.786b3819-b391-4be0-8e8d-0d0ad076dc1c@github.com>

On Mon, 4 Nov 2024 20:29:23 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:
> 
>   Update copyright years

I have now searched for `@[0-9]` to find instances of "stdcall-style" symbol names, and fixed those. I have also done a wide sweep of searching for "@" in general over the code base, which (unsurprisingly) generated a sh*tload of hits. I tried to sift through this, using some mental heuristics to skip those that are likely to be irrelevant, and scrutinized some other more carefully, to identify any other code that might be working with name mangling/parsing. I found no such code, outside of what I had already previously located.

At this point, I believe I have resolved all outstanding issues from the reviews, and also finished fixing up the additional removal of the 32-bit Windows calling convention remnants.

>From my PoV, what remains now is for me to repeat the in-depth testing of this PR, and to wait for the JEP to become targeted. 

@shipilev @erikj79 @vnkozlov @kimbarrett I'd appreciate a re-review from you at the current commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455648651
PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455651750

From ihse at openjdk.org  Mon Nov  4 20:42:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:42:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@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: jvm_md.h was included, but not jvm.h...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/40291b9b..9b10e74c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28-29

  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 sspitsyn at openjdk.org  Mon Nov  4 20:57:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Nov 2024 20:57:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
Message-ID: <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>

On Mon, 4 Nov 2024 18:18: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 three additional commits since the last revision:
> 
>  - Update comment block in objectMonitor.cpp
>  - Fix issue with unmounted virtual thread when dumping heap
>  - Remove ThawBase::possibly_adjust_frame()

src/hotspot/share/runtime/continuation.cpp line 134:

> 132:   return true;
> 133: }
> 134: #endif // INCLUDE_JVMTI

Could you, please, consider the simplification below?


#if INCLUDE_JVMTI
// return true if started vthread unmount
bool jvmti_unmount_begin(JavaThread* target) {
  assert(!target->is_in_any_VTMS_transition(), "must be");

  // Don't preempt if there is a pending popframe or earlyret operation. This can
  // be installed in start_VTMS_transition() so we need to check it here.
  if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
    JvmtiThreadState* state = target->jvmti_thread_state();
    if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
      return false;
    }
  }
  // Don't preempt in case there is an async exception installed since
  // we would incorrectly throw it during the unmount logic in the carrier.
  if (target->has_async_exception_condition()) {
    return false;
  }
  if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
    JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
  } else {
    target->set_is_in_VTMS_transition(true);
    // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
  }
  return false;
}

static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
  if (target->is_in_VTMS_transition()) {
    // We caught target at the end of a mount transition.
    return false;
  }
  return true;
}
#endif // INCLUDE_JVMTI
...
static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
  assert(java_lang_VirtualThread::is_instance(vthread), "");
  if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
    return false;
  }
  return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
}
...
int Continuation::try_preempt(JavaThread* target, oop continuation) {
  verify_preempt_preconditions(target, continuation);

  if (LockingMode == LM_LEGACY) {
    return freeze_unsupported;
  }
  if (!is_safe_vthread_to_preempt(target, target->vthread())) {
    return freeze_pinned_native;
  }
  JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
  int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
  log_trace(continuations, preempt)("try_preempt: %d", res);
  return res;
}


The following won't be needed:

target->set_pending_jvmti_unmount_event(true);

jvmtiThreadState.cpp:

+  if (thread->pending_jvmti_unmount_event()) {
+    assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted");
+    JvmtiExport::post_vthread_unmount(vthread);
+    thread->set_pending_jvmti_unmount_event(false);
+  }


As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585

From fyang at openjdk.org  Tue Nov  5 00:20:53 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 00:20:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>

On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>
> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 

> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

I agree with @pchilano in that we are fine with these places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437

From fyang at openjdk.org  Tue Nov  5 00:26:54 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 00:26:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>
Message-ID: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@github.com>

On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.
>
>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
> 
> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
> 
>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
> 
> I agree with @pchilano in that we are fine with these places.

> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395

From pchilanomate at openjdk.org  Tue Nov  5 01:40:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:40:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
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: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@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 five additional commits since the last revision:

 - Add oopDesc::has_klass_gap() check
 - Rename waitTimeout/set_waitTimeout accessors
 - Revert suggestion to ThawBase::new_stack_frame
 - Improve JFR pinned reason in event
 - Use freeze_result consistently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/11396312..79189f9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28-29

  Stats: 439 lines in 21 files changed: 123 ins; 261 del; 55 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 Nov  5 01:43:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@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>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>
 <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@github.com>
Message-ID: <B6yKYX170EzYJUUBWPDAOJmNDGNVRsSXi4OBHWmh4TU=.59f8b023-22b5-4e44-9a49-55c733a3d50a@github.com>

On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
>> 
>> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
>> 
>>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
>> 
>> I agree with @pchilano in that we are fine with these places.
>
>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
> 
> Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499

From pchilanomate at openjdk.org  Tue Nov  5 01:43:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>
Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.9026ecf7-915c-4366-afff-30ec82ec6f98@github.com>

On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>> 
>>> 2105: 
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107:   return vthread->long_field(_timeout_offset);
>> 
>> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??
>
> It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

Renamed accessors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772

From pchilanomate at openjdk.org  Tue Nov  5 01:43:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@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>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>
 <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@github.com>
Message-ID: <FJEpZFaGxULmsFhOGyiaLRoIWxL2o9bKBNbo4LWqlrs=.a80e1774-7171-49cb-94fa-650aca3a0c8f@github.com>

On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> 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.
>
> This code in `StackChunkAllocator::initialize` mimics the clearing code in:
> 
> void MemAllocator::mem_clear(HeapWord* mem) const {
>   assert(mem != nullptr, "cannot initialize null object");
>   const size_t hs = oopDesc::header_size();
>   assert(_word_size >= hs, "unexpected object size");
>   oopDesc::set_klass_gap(mem, 0);
>   Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
> }
> 
> 
> but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:
> 
>   if (oopDesc::has_klass_gap()) {
>     oopDesc::set_klass_gap(mem, 0);
>   }
> 
> 
> So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

Thanks for confirming. I added the check here which I think should cover any merge order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946

From pchilanomate at openjdk.org  Tue Nov  5 01:50:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:50:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>

On Tue, 5 Nov 2024 01:40: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 five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

I brought some JFR changes from the loop repo that improve the reported reason when pinning.
@mgronlun @egahlin Could any of you review these JFR changes? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504

From tprinzing at openjdk.org  Tue Nov  5 03:24:51 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 5 Nov 2024 03:24:51 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v2]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <hKkxjQV5Zvtk-PxlM0S29AfljzrB-QFwz6YklaEfOu8=.9d24be84-b4a4-4190-8551-3aaa7349678a@github.com>

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

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

  Added support for connection failure and non-blocking connections.
  
  If an exception is thrown while attempting a connection, the message
  from the exception is stored in the event.  The start time of the
  initial connect call is stored and used when a finishConnect call is
  successful or an exception is thrown.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/05227c9d..7113bd75

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

  Stats: 91 lines in 4 files changed: 44 ins; 14 del; 33 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 amitkumar at openjdk.org  Tue Nov  5 04:15:54 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 5 Nov 2024 04:15:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <jj6iCskb42eGr6L5b_roCs03SXecaECIHTT5TRMmOHg=.2e640db9-2c3e-49b5-84a2-50edf7daf20e@github.com>

On Tue, 5 Nov 2024 01:40: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 five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

Hi @pchilano, 

I see couple of failures on s390x, can you apply this patch: 


diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
index f342240f3ca..d28b4579824 100644
--- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
@@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1
 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp1;
@@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
   // If csg succeeds then CR=EQ, otherwise, register zero is filled
   // with the current owner.
   z_lghi(zero, 0);
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
 
   // Store a non-null value into the box.
   z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box);
@@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 
   BLOCK_COMMENT("fast_path_recursive_lock {");
   // Check if we are already the owner (recursive lock)
-  z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above
+  z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above
   z_brne(done); // not a recursive lock
 
   // Current thread already owns the lock. Just increment recursion count.
@@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp2;
@@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg
   // Handle existing monitor.
   bind(object_has_monitor);
 
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
   z_brne(done);
 
   BLOCK_COMMENT("fast_path_recursive_unlock {");
@@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t
 }
 
 void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) {
-  assert_different_registers(obj, box, tmp1, tmp2);
+  assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch);
 
   // Handle inflated monitor.
   NearLabel inflated;
@@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe
     // If csg succeeds then CR=EQ, otherwise, register zero is filled
     // with the current owner.
     z_lghi(zero, 0);
-    z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-    z_csg(zero, Z_R1_scratch, owner_address);
+    z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+    z_csg(zero, Z_R0_scratch, owner_address);
     z_bre(monitor_locked);
 
     // Check if recursive.
-    z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction
+    z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction
     z_brne(slow_path);
 
     // Recursive


CC: @RealLucy

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800

From fyang at openjdk.org  Tue Nov  5 06:35:52 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 06:35:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@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>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>
Message-ID: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@github.com>

On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Here's my suggested C2 change:
>> 
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
>> @@ -3692,14 +3692,13 @@ encode %{
>>        __ post_call_nop();
>>      } else {
>>        Label retaddr;
>> +      // Make the anchor frame walkable
>>        __ adr(rscratch2, retaddr);
>> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>>        __ lea(rscratch1, RuntimeAddress(entry));
>> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>        __ blr(rscratch1);
>>        __ bind(retaddr);
>>        __ post_call_nop();
>> -      __ add(sp, sp, 2 * wordSize);
>>      }
>>      if (Compile::current()->max_vector_size() > 0) {
>>        __ reinitialize_ptrue();
>
> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
> @RealFYang I made the equivalent change for riscv, could you verify it's okay?

@pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
`hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.

BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
Do you mind adding following small addon change to fix it? Thanks.

diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 84a292242c3..ac28f4b3514 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   if (LockingMode != LM_LEGACY) {
     // Check preemption for Object.wait()
     Label not_preempted;
-    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ beqz(t0, not_preempted);
+    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
+    __ beqz(t1, not_preempted);
     __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ jr(t0);
+    __ jr(t1);
     __ bind(native_return);
     __ restore_after_resume(true /* is_native */);
     // reload result_handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495

From egahlin at openjdk.org  Tue Nov  5 08:02:54 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 5 Nov 2024 08:02:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>

On Tue, 5 Nov 2024 01:40: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 five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:

https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html

(Note: The fact that the event is now written in the JVM doesn't determine the category.)

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

The label should be "Blocking Operation" with a capital "O".

Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025

From alanb at openjdk.org  Tue Nov  5 08:22:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 08:22:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
Message-ID: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>

On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
> 
> (Note: The fact that the event is now written in the JVM doesn't determine the category.)

Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value that was in the `@Catalog` wasn't carried over.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229

From sspitsyn at openjdk.org  Tue Nov  5 11:38:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Nov 2024 11:38:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>

On Tue, 5 Nov 2024 01:40: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 five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/runtime/objectMonitor.cpp line 1643:

> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);

We post a JVMTI `MonitorWaited` event here for a virtual thread.
A couple of questions on this:
- Q1: Is this posted after the `VirtualThreadMount` extension event posted?
         Unfortunately, it is not easy to make this conclusion.
- Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
          Does it post the `MonitorWaited` event for this virtual thread as well?
          If not, then it is not clear how posting for virtual thread is avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889

From alanb at openjdk.org  Tue Nov  5 12:07:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 12:07:29 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS
In-Reply-To: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
Message-ID: <k08j8aRMVgqAjdgGC-VdbM41s_7gGgsv27Y0F0aGVkc=.f32de9a0-3e26-4740-b757-cf384192b89a@github.com>

On Mon, 4 Nov 2024 19:30:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.

src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java line 400:

> 398:      * We hard code fd to FD_ATCWD and flags to AT_SYMLINK_NOFOLLOW.
> 399:      */
> 400:     static void utimensat(UnixPath path, long times0, long times1)

The *at methods that are supposed to map 1-1 to the similarly named sys calls so I'm a bit uncomfortable having this one work differently and hardcode dirfd  to FD_ATCWD. I wonder if we could generate a value for FD_ATCWD in UnixConstants.java.template so that the use site would more closely match the sys call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1829236119

From pchilanomate at openjdk.org  Tue Nov  5 14:34:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:34:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v31]
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: <jjaAbty4zUUXNkpiQA69cO_Lqw5sPLTvlGJVrmSgsjQ=.3c196de8-1e8e-4914-983b-02e428449d3c@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:

 - Fixes to JFR metadata.xml
 - Fix return miss prediction in generate_native_entry for riscv
 - Fix s390x failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/79189f9b..124efa0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29-30

  Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 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 Nov  5 14:34:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:34:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@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>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>
 <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@github.com>
Message-ID: <Z0J2vBm4Z7jT_aibhLEjVlN3tMtVt4kPuxrXg28hRmY=.0550810f-3fc6-4221-8da6-128a84012f5f@github.com>

On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
>> @RealFYang I made the equivalent change for riscv, could you verify it's okay?
>
> @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
> `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.
> 
> BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
> Do you mind adding following small addon change to fix it? Thanks.
> 
> diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> index 84a292242c3..ac28f4b3514 100644
> --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
>    if (LockingMode != LM_LEGACY) {
>      // Check preemption for Object.wait()
>      Label not_preempted;
> -    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ beqz(t0, not_preempted);
> +    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> +    __ beqz(t1, not_preempted);
>      __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ jr(t0);
> +    __ jr(t1);
>      __ bind(native_return);
>      __ restore_after_resume(true /* is_native */);
>      // reload result_handler

Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335

From pchilanomate at openjdk.org  Tue Nov  5 14:37:54 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>
Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.b9ae55cd-0172-40f4-bb51-cb72eadac61d@github.com>

On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> I brought some JFR changes from the loom repo that improve the reported reason when pinning.
> @mgronlun @egahlin Could any of you review these JFR changes? Thanks.

> Hi @pchilano,
> 
> I see couple of failures on s390x, can you apply this patch:
> 
Thanks @offamitkumar. Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726

From pchilanomate at openjdk.org  Tue Nov  5 14:37:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
 <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>
Message-ID: <FST2J8IQ3-HRqwpZqe44YLVavuGNcakXyrIKmnieBU4=.ea5fd5c7-1b2f-4265-9ff6-9165a4327d93@github.com>

On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 160:
>> 
>>> 158: 
>>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
>> 
>> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
>> 
>> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
>> 
>> (Note: The fact that the event is now written in the JVM doesn't determine the category.)
>
> Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765

From aboldtch at openjdk.org  Tue Nov  5 14:37:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 5 Nov 2024 14:37:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>

On Tue, 5 Nov 2024 01:40: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 five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:

> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Suggestion:

  assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866

From pchilanomate at openjdk.org  Tue Nov  5 14:37:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
Message-ID: <O8JULSt20GzECs148szBdunnT7m3Gq1N3MraPGVogm4=.2639d95d-b377-42c9-a914-deb892072207@github.com>

On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> The label should be "Blocking Operation" with a capital "O".
> 
> Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128

From ihse at openjdk.org  Tue Nov  5 14:51:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Nov 2024 14:51:47 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <ZJZkX6Asec26xKuYhDfNk2SYI9h_BivdZmiqOMMpzi4=.4abcb053-fc1c-4c01-aeb0-870c093a9d7c@github.com>

On Mon, 4 Nov 2024 20:42:59 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: jvm_md.h was included, but not jvm.h...

This has now passed internal CI testing tier1-5 (except for one test that also fails in mainline).

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2457376495

From bpb at openjdk.org  Tue Nov  5 16:04:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 16:04:28 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS
In-Reply-To: <k08j8aRMVgqAjdgGC-VdbM41s_7gGgsv27Y0F0aGVkc=.f32de9a0-3e26-4740-b757-cf384192b89a@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <k08j8aRMVgqAjdgGC-VdbM41s_7gGgsv27Y0F0aGVkc=.f32de9a0-3e26-4740-b757-cf384192b89a@github.com>
Message-ID: <vmPPYXo5poKaoqjG4lQSmSPvI70hDSsFaTLK9tHAszA=.6bbe018a-cb5f-44c2-b210-441b15feff83@github.com>

On Tue, 5 Nov 2024 12:04:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if we could generate a value for FD_ATCWD in UnixConstants.java.template so that the use site would more closely match the sys call.

Sure, no problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1829617184

From tprinzing at openjdk.org  Tue Nov  5 16:48:14 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 5 Nov 2024 16:48:14 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v3]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>

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

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

  improved exception names and handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/7113bd75..a8898ffc

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

  Stats: 33 lines in 3 files changed: 9 ins; 8 del; 16 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 kbarrett at openjdk.org  Tue Nov  5 17:11:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 5 Nov 2024 17:11:53 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>

On Mon, 4 Nov 2024 20:42:59 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: jvm_md.h was included, but not jvm.h...

I kind of wish the __cdecl / __stdcall changes had been done separately.  Oh well.

src/hotspot/os/windows/os_windows.cpp line 5820:

> 5818: }
> 5819: 
> 5820: // FIXME

???

src/hotspot/os/windows/os_windows.cpp line 5863:

> 5861:     return nullptr;
> 5862:   }
> 5863: 

[pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.]
The calculation of `len` is wasting a byte when `lib_name` is null.  The `+2` accounts for the
terminating `NUL` and the underscore separator between the sym_name part and the lib_name
part.  That underscore isn't added when there isn't a lib_name part.  I think the simplest fix would
be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation.  And add some
commentary.

This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment
padding, and it slightly further complicates the calculation.  But additional commentary would still
be desirable, to guide the next careful reader.  In which case it might be simpler to describe the
fixed version.

Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup
change.

src/hotspot/share/include/jvm.h line 1165:

> 1163: #define AGENT_ONLOAD_SYMBOLS    {"Agent_OnLoad"}
> 1164: #define AGENT_ONUNLOAD_SYMBOLS  {"Agent_OnUnload"}
> 1165: #define AGENT_ONATTACH_SYMBOLS  {"Agent_OnAttach"}

There is more cleanup that can be done here.  These definitions are used as
array initializers (hence the surrounding curly braces).  They are now always
singleton, rather than sometimes having 2 elements.  The uses iterate over the
now always singleton arrays.  Those iterations are no longer needed and could
be eliminated.  And these macros could be eliminated, using the corresponding
string directly in each use.  This can all be done as a followup change.

src/java.base/share/native/libjava/NativeLibraries.c line 67:

> 65:         strcat(jniEntryName, "_");
> 66:         strcat(jniEntryName, cname);
> 67:     }

I would prefer this be directly inlined at the sole call (in findJniFunction),
to make it easier to verify there aren't any buffer overrun problems. (I don't
think there are, but looking at this in isolation triggered warnings in my
head.)

Also, it looks like all callers of findJniFunction ensure the cname argument
is non-null. So there should be no need to handle the null case in
findJniFunction (other than perhaps an assert or something). That could be
addressed in a followup. (I've already implicitly suggested elsewhere in this
PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
thing.)

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2415002837
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829659373
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828969105
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829478432
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829684759

From alanb at openjdk.org  Tue Nov  5 17:23:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 17:23:30 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v3]
In-Reply-To: <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>
Message-ID: <cVRdc_386fJlJrDNCHuNE87a2c9NzTer3_mSuYByNOg=.a75b5f70-a534-4f9a-a700-5582d69e1569@github.com>

On Tue, 5 Nov 2024 16:48:14 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved exception names and handling

Discussed with Tim as there are a number of issues that will need attention. A SocketConnectEvent should only be "offered" for connect events, not cases such as "already connected" or "socket closed". For SocketChannel there is also a socket adaptor (blockingConnect method) that will need to be updated. The non-blocking connect/finishConnect is complicated and there are several issues there. Finally, remoteAddress requires stateLock.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2457759513

From bpb at openjdk.org  Tue Nov  5 17:58:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 17:58:10 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v2]
In-Reply-To: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
Message-ID: <c_hrIF5diOn5ZX4p0EgAP5uL6ajpUmmhlxQ0RUk-2RE=.950afcc6-4ed4-4f77-9bfb-1cc1623b4674@github.com>

> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.

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

  8343417: Make Java method utimensat() signature match that of the corresponding system call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21886/files
  - new: https://git.openjdk.org/jdk/pull/21886/files/76280431..26feef6c

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

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

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

From bpb at openjdk.org  Tue Nov  5 17:58:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 17:58:10 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v2]
In-Reply-To: <vmPPYXo5poKaoqjG4lQSmSPvI70hDSsFaTLK9tHAszA=.6bbe018a-cb5f-44c2-b210-441b15feff83@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <k08j8aRMVgqAjdgGC-VdbM41s_7gGgsv27Y0F0aGVkc=.f32de9a0-3e26-4740-b757-cf384192b89a@github.com>
 <vmPPYXo5poKaoqjG4lQSmSPvI70hDSsFaTLK9tHAszA=.6bbe018a-cb5f-44c2-b210-441b15feff83@github.com>
Message-ID: <o4CCh7XG5uoHh1Y1vqTfs507kAkPHr9LNiNxf57cm24=.c28bb4f0-03e4-4d2b-b0c3-d35af3461ac6@github.com>

On Tue, 5 Nov 2024 16:02:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java line 400:
>> 
>>> 398:      * We hard code fd to FD_ATCWD and flags to AT_SYMLINK_NOFOLLOW.
>>> 399:      */
>>> 400:     static void utimensat(UnixPath path, long times0, long times1)
>> 
>> The *at methods that are supposed to map 1-1 to the similarly named sys calls so I'm a bit uncomfortable having this one work differently and hardcode dirfd  to FD_ATCWD. I wonder if we could generate a value for FD_ATCWD in UnixConstants.java.template so that the use site would more closely match the sys call.
>
>> I wonder if we could generate a value for FD_ATCWD in UnixConstants.java.template so that the use site would more closely match the sys call.
> 
> Sure, no problem.

So changed in 26feef6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1829786228

From bpb at openjdk.org  Tue Nov  5 17:58:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 17:58:35 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: <a7tVih_-xTKHa7_mXMsoMWddPThkDXgTZR0vn7bOC04=.d07f1cb4-eed0-404b-9015-18e8cc86b80e@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

continue;

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

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

From mullan at openjdk.org  Tue Nov  5 18:30:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:30:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v7]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <djVIdf6f-DCXWXIZXcS0tr5pnTYNYUi_qzbrtKGbUB0=.ce9aafa1-bf99-4f36-a520-a4b6ff670686@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 213 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - Merge branch 'master' into jep486
 - Remove left-over paragraph about SM use from LoggerFinder
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 203 more: https://git.openjdk.org/jdk/compare/f69b6016...51d2a2a3

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=06
  Stats: 68938 lines in 1889 files changed: 2490 ins; 62600 del; 3848 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 alanb at openjdk.org  Tue Nov  5 18:41:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 18:41:32 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v2]
In-Reply-To: <c_hrIF5diOn5ZX4p0EgAP5uL6ajpUmmhlxQ0RUk-2RE=.950afcc6-4ed4-4f77-9bfb-1cc1623b4674@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <c_hrIF5diOn5ZX4p0EgAP5uL6ajpUmmhlxQ0RUk-2RE=.950afcc6-4ed4-4f77-9bfb-1cc1623b4674@github.com>
Message-ID: <IrqSovqEFNnaQrDfnx5fCmsTLuv5SXztx5Ac-GOFRks=.b7609330-f912-4b70-98bd-fdc147686d1b@github.com>

On Tue, 5 Nov 2024 17:58:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343417: Make Java method utimensat() signature match that of the corresponding system call

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 88:

> 86:                         useLutimes = lutimesSupported();
> 87:                 }
> 88:                 if (!useUtimensat && !useLutimes) {

Changing the utimesat method to match the sys call is good. Now I wonder if we go further and use fd from openForAttribtueAccess(false) with utimesat. That would remove the window between the lstat and  utimesat(AT_FDCWD...) where the file may be replaced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1829838511

From mullan at openjdk.org  Tue Nov  5 18:58:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:58:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@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 217 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=07
  Stats: 68934 lines in 1889 files changed: 2490 ins; 62600 del; 3844 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 Nov  5 19:24:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 19:24:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
 <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
Message-ID: <oObdOTPzC4tiiWiwoqy9kJo6t60O7P7kqlnArXu9wbc=.925ca6c4-fa1d-4433-bff2-70b3e66bbce8@github.com>

On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.
>
> Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ab586f6619ca5f7e213876219abf61a36155735c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1829886748

From bpb at openjdk.org  Tue Nov  5 20:08:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 20:08:35 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v2]
In-Reply-To: <IrqSovqEFNnaQrDfnx5fCmsTLuv5SXztx5Ac-GOFRks=.b7609330-f912-4b70-98bd-fdc147686d1b@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <c_hrIF5diOn5ZX4p0EgAP5uL6ajpUmmhlxQ0RUk-2RE=.950afcc6-4ed4-4f77-9bfb-1cc1623b4674@github.com>
 <IrqSovqEFNnaQrDfnx5fCmsTLuv5SXztx5Ac-GOFRks=.b7609330-f912-4b70-98bd-fdc147686d1b@github.com>
Message-ID: <N4cd8PI80p21hAN5sy5Jq87EBK1oWwpsiE605BVhqeU=.46c36790-f62d-4ce8-abd2-d56cae6540fa@github.com>

On Tue, 5 Nov 2024 18:39:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343417: Make Java method utimensat() signature match that of the corresponding system call
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 88:
> 
>> 86:                         useLutimes = lutimesSupported();
>> 87:                 }
>> 88:                 if (!useUtimensat && !useLutimes) {
> 
> Changing the utimesat method to match the sys call is good. Now I wonder if we go further and use fd from openForAttribtueAccess(false) with utimesat. That would remove the window between the lstat and  utimesat(AT_FDCWD...) where the file may be replaced.

Indeed UnixFileAttributes.get calls lstat. Calling symlink.openForAttributeAccess(false) however yields

java.nio.file.FileSystemException: symlink: No such file or directory or unable to access attributes of symbolic link

According to [symlink(7)](https://www.man7.org/linux/man-pages/man7/symlink.7.html):

The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).

It looks like futimens will not work with a symlink's fd so that utimensat is necessary here to obtain nsec precision. I don't see a way to close the window between lstat and utimensat, which anyway was already there for the lutimes case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1829937573

From mullan at openjdk.org  Tue Nov  5 20:10:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 20:10:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
Message-ID: <nKDNw4mah9BaszGzCs83ttYt9TzQdfhGCiO_8quB0vQ=.4234a809-ebc3-4aa5-8265-08f8cebb1bf5@github.com>

On Tue, 5 Nov 2024 18:58:22 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 217 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Remove "access" and "policy" options from debug help.
>  - Merge branch 'master' into jep486
>  - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
>  - remove MainClassCantBeLoadedTest from problemlisting
>  - remove LauncherErrors test from problemlisting
>  - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

The latest update includes:
- merging with the mainline sources
- a couple of test removals from the ProblemList for tests that no longer apply
- removal of the "policy" and "access" options from the `-Djava.security.debug` help option.
- a small update to remove some SM specific text from the `System.LoggerFinder` class description.
- copyright header updates for several tests that were previously modified
- addition of a few client manual tests to the ProblemList that have dependencies on the Security Manager and will be resolved later

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2458058335

From pchilanomate at openjdk.org  Tue Nov  5 23:55:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 23:55:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
Message-ID: <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>

On Mon, 4 Nov 2024 20:55:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update comment block in objectMonitor.cpp
>>  - Fix issue with unmounted virtual thread when dumping heap
>>  - Remove ThawBase::possibly_adjust_frame()
>
> src/hotspot/share/runtime/continuation.cpp line 134:
> 
>> 132:   return true;
>> 133: }
>> 134: #endif // INCLUDE_JVMTI
> 
> Could you, please, consider the simplification below?
> 
> 
> #if INCLUDE_JVMTI
> // return true if started vthread unmount
> bool jvmti_unmount_begin(JavaThread* target) {
>   assert(!target->is_in_any_VTMS_transition(), "must be");
> 
>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>   // be installed in start_VTMS_transition() so we need to check it here.
>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>     JvmtiThreadState* state = target->jvmti_thread_state();
>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>       return false;
>     }
>   }
>   // Don't preempt in case there is an async exception installed since
>   // we would incorrectly throw it during the unmount logic in the carrier.
>   if (target->has_async_exception_condition()) {
>     return false;
>   }
>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>   } else {
>     target->set_is_in_VTMS_transition(true);
>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>   }
>   return false;
> }
> 
> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>   if (target->is_in_VTMS_transition()) {
>     // We caught target at the end of a mount transition.
>     return false;
>   }
>   return true;
> }
> #endif // INCLUDE_JVMTI
> ...
> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>     return false;
>   }
>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
> }
> ...
> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>   verify_preempt_preconditions(target, continuation);
> 
>   if (LockingMode == LM_LEGACY) {
>     return freeze_unsupported;
>   }
>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>     return freeze_pinned_native;
>   }
>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>   log_trace(continuations, preempt)("try_preempt: %d", res);
>   return res;
> }
> 
> 
> The following won't be needed:
> 
> target->set_pending_jvmti_unmou...

Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838

From pchilanomate at openjdk.org  Tue Nov  5 23:55:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 23:55:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
 <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
Message-ID: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>

On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 134:
>> 
>>> 132:   return true;
>>> 133: }
>>> 134: #endif // INCLUDE_JVMTI
>> 
>> Could you, please, consider the simplification below?
>> 
>> 
>> #if INCLUDE_JVMTI
>> // return true if started vthread unmount
>> bool jvmti_unmount_begin(JavaThread* target) {
>>   assert(!target->is_in_any_VTMS_transition(), "must be");
>> 
>>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>>   // be installed in start_VTMS_transition() so we need to check it here.
>>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>>     JvmtiThreadState* state = target->jvmti_thread_state();
>>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>>       return false;
>>     }
>>   }
>>   // Don't preempt in case there is an async exception installed since
>>   // we would incorrectly throw it during the unmount logic in the carrier.
>>   if (target->has_async_exception_condition()) {
>>     return false;
>>   }
>>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>>   } else {
>>     target->set_is_in_VTMS_transition(true);
>>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>>   }
>>   return false;
>> }
>> 
>> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>>   if (target->is_in_VTMS_transition()) {
>>     // We caught target at the end of a mount transition.
>>     return false;
>>   }
>>   return true;
>> }
>> #endif // INCLUDE_JVMTI
>> ...
>> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>>     return false;
>>   }
>>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
>> }
>> ...
>> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>>   verify_preempt_preconditions(target, continuation);
>> 
>>   if (LockingMode == LM_LEGACY) {
>>     return freeze_unsupported;
>>   }
>>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>>     return freeze_pinned_native;
>>   }
>>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>>   log_trace(con...
>
> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.

[1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411

From pchilanomate at openjdk.org  Wed Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
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: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@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:

  Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/124efa0a..c0c7e6cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30-31

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
Message-ID: <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>

On Tue, 5 Nov 2024 11:35:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>  Is this posted after the VirtualThreadMount extension event posted?
>
It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909

From pchilanomate at openjdk.org  Wed Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
Message-ID: <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>

On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>> 
>>> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
>>> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);
>> 
>> We post a JVMTI `MonitorWaited` event here for a virtual thread.
>> A couple of questions on this:
>> - Q1: Is this posted after the `VirtualThreadMount` extension event posted?
>>          Unfortunately, it is not easy to make this conclusion.
>> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
>>           Does it post the `MonitorWaited` event for this virtual thread as well?
>>           If not, then it is not clear how posting for virtual thread is avoided.
>
>>  Is this posted after the VirtualThreadMount extension event posted?
>>
> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

> The JvmtiExport::post_monitor_waited() is called at the line 1801.
> Does it post the MonitorWaited event for this virtual thread as well?
>
That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475

From pchilanomate at openjdk.org  Wed Nov  6 00:08:17 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>
Message-ID: <mRFEu40W_IpSm-Pd85OFh6qH5T2M2GJyr3EoB72MZRQ=.d60717b6-4096-4e7a-adea-af19a1c18241@github.com>

On Tue, 5 Nov 2024 14:35:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:
> 
>> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
>> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
>> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Suggestion:
> 
>   assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529

From tprinzing at openjdk.org  Wed Nov  6 00:15:44 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 6 Nov 2024 00:15:44 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>

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

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

  suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/a8898ffc..ce9d39e2

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

  Stats: 76 lines in 2 files changed: 49 ins; 15 del; 12 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 dholmes at openjdk.org  Wed Nov  6 01:00:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 01:00:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>

On Mon, 4 Nov 2024 20:42:59 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: jvm_md.h was included, but not jvm.h...

I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

src/hotspot/os/windows/os_windows.cpp line 510:

> 508: // Thread start routine for all newly created threads.
> 509: // Called with the associated Thread* as the argument.
> 510: static unsigned thread_native_entry(void* t) {

Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2417056020
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1830259353

From bpb at openjdk.org  Wed Nov  6 01:31:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Nov 2024 01:31:20 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v3]
In-Reply-To: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
Message-ID: <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>

> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.

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

  8343417: Use utimensat or lutimes when not following links

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21886/files
  - new: https://git.openjdk.org/jdk/pull/21886/files/26feef6c..08f5b7df

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

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

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

From amenkov at openjdk.org  Wed Nov  6 01:47:45 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 6 Nov 2024 01:47:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
Message-ID: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>

On Wed, 6 Nov 2024 00:58:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170
`On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.`

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458534929

From bpb at openjdk.org  Wed Nov  6 03:13:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Nov 2024 03:13:34 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v2]
In-Reply-To: <N4cd8PI80p21hAN5sy5Jq87EBK1oWwpsiE605BVhqeU=.46c36790-f62d-4ce8-abd2-d56cae6540fa@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <c_hrIF5diOn5ZX4p0EgAP5uL6ajpUmmhlxQ0RUk-2RE=.950afcc6-4ed4-4f77-9bfb-1cc1623b4674@github.com>
 <IrqSovqEFNnaQrDfnx5fCmsTLuv5SXztx5Ac-GOFRks=.b7609330-f912-4b70-98bd-fdc147686d1b@github.com>
 <N4cd8PI80p21hAN5sy5Jq87EBK1oWwpsiE605BVhqeU=.46c36790-f62d-4ce8-abd2-d56cae6540fa@github.com>
Message-ID: <DvsDNxP6XJhbfrHUjAOA1pDfR8SqkWGRltnCy4ePaHQ=.2f283de2-1be7-4ea1-9db2-c462c60c6470@github.com>

On Tue, 5 Nov 2024 20:05:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 88:
>> 
>>> 86:                         useLutimes = lutimesSupported();
>>> 87:                 }
>>> 88:                 if (!useUtimensat && !useLutimes) {
>> 
>> Changing the utimesat method to match the sys call is good. Now I wonder if we go further and use fd from openForAttribtueAccess(false) with utimesat. That would remove the window between the lstat and  utimesat(AT_FDCWD...) where the file may be replaced.
>
> Indeed UnixFileAttributes.get calls lstat. Calling symlink.openForAttributeAccess(false) however yields
> 
> java.nio.file.FileSystemException: symlink: No such file or directory or unable to access attributes of symbolic link
> 
> According to [symlink(7)](https://www.man7.org/linux/man-pages/man7/symlink.7.html):
> 
> The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).
> 
> It looks like futimens will not work with a symlink's fd so that utimensat is necessary here to obtain nsec precision. I don't see a way to close the window between lstat and utimensat, which anyway was already there for the lutimes case.

I don't think that the logic in 08f5b7d is quite correct yet. It might be possible if followLinks is false and the file is not a symlink, that lutimes would be used even though futimens is supported, thus decreasing the timestamp resolution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1830334196

From jwaters at openjdk.org  Wed Nov  6 04:43:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 6 Nov 2024 04:43:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
Message-ID: <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>

On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458712195

From dholmes at openjdk.org  Wed Nov  6 05:32:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 05:32:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
In-Reply-To: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
Message-ID: <FQ_XTZ1NAU6pE5K9IzwtAJ2irQjr-Tu46z6xt-POjQk=.41c27641-2a45-4915-ac36-519a3abc3243@github.com>

On Wed, 6 Nov 2024 00:08: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 one additional commit since the last revision:
> 
>   Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456

From dholmes at openjdk.org  Wed Nov  6 05:55:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 05:55:47 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
Message-ID: <91oCFKrjKmyjkaT3dBRRcpao4NNde2DXg39vjvBn7Wk=.893ab420-92f3-4bda-8744-4a801a07f95c@github.com>

On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> On ARM and x64 processors, __stdcall is accepted and ignored by the compiler;

@alexmenkov and @TheShermanTanker , I stand corrected and my apologies to @magicus .

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458778303

From aboldtch at openjdk.org  Wed Nov  6 06:39:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 06:39:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
In-Reply-To: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
Message-ID: <k2pGIDqjtzechkzb2pm4a71NnFPihIonlD7mh5ySWIs=.53c0b7fb-da75-4bdd-a875-4abccc3e1992@github.com>

On Wed, 6 Nov 2024 00:08: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 one additional commit since the last revision:
> 
>   Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

Good work! I'll approve the GC related changes.

There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.

Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.

A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.

// the sp of the oldest known interpreted/call_stub frame inside the
// continuation that we know about

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171

From alanb at openjdk.org  Wed Nov  6 08:05:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 08:05:36 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>

On Wed, 6 Nov 2024 00:15:44 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2:

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

I assume you didn't mean to change that.

src/jdk.jfr/share/conf/jfr/profile.jfc line 741:

> 739:       <setting name="stackTrace">true</setting>
> 740:       <setting name="threshold" control="socket-threshold">10 ms</setting>
> 741:     </event>

In default.jfr the threshold for the socket events is 20ms, but 10ms in profile.jfc. Is that intentional?

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106:

> 104: 
> 105:                 try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) {
> 106:                     addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket()));

This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded.

test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108:

> 106:                 try (Socket s = new Socket()) {
> 107:                     s.connect(ss.getLocalSocketAddress());
> 108:                     addExpectedEvent(IOEvent.createSocketConnectEvent(s));

This is Socket.connect success case, I assume we'll need a test for fail case too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830512546
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830516492
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830545551
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830537634

From alanb at openjdk.org  Wed Nov  6 08:10:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 08:10:31 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <xqNMNjbZtes0NQ0qvL2GBBwQhPb0MX_ePQkLwltaEsw=.a6945963-6b0f-431a-ad5b-33dcc51265eb@github.com>

On Wed, 6 Nov 2024 00:15:44 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

The update in ce9d39e2 has the changes that I discussed with Tim yesterday. Specifically, it fixes several issues with the non-blocking case, only records an event if the connect method actually attempts to establish a connection, and fixes the socket adaptor. So I think this to NioSocketImpl and SocketChannelImpl are good now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2458949631

From stuefe at openjdk.org  Wed Nov  6 09:15:11 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Nov 2024 09:15:11 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
 <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
Message-ID: <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>

On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention.

I am sure __stdcall is ignored by the compiler on x64 or arm64.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459078526

From stuefe at openjdk.org  Wed Nov  6 09:15:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Nov 2024 09:15:12 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
 <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
 <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>
Message-ID: <wRLgGr7tu6TxChDieo2Mc6HWK51JC-Hjr6eBYCUPqAU=.7d627968-161a-4ce8-98be-8dc2a329868d@github.com>

On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!
> 
> stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention.
> 
> I am sure __stdcall is ignored by the compiler on x64 or arm64.

Never mind my noise, other people did already answer this :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459080708

From alanb at openjdk.org  Wed Nov  6 09:20:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 09:20:31 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v3]
In-Reply-To: <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
Message-ID: <JLpOgxc3-coB1p4sM4X0As6DQ1q24GJdwFR8Sn-y_Iw=.ad168ea1-fc32-445e-9ebf-d428ce7f1b3a@github.com>

On Wed, 6 Nov 2024 01:31:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343417: Use utimensat or lutimes when not following links

I think what you have is correct now but it's hard to follow as it's one of 4 sys calls. What would you think about use a local enum class and a switch and get rid of the 4 booleans. Alternatively, invert the setup so that if the follow case is first. The follow case should map to fd+futimens or utimes, no need for futimes. For the !follow case then it should map to lutimesnsat or lutimes. I realise this is adding to the work on this change but right now it's hard for anyone to touch this method due to the many cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/21886#issuecomment-2459090106

From alanb at openjdk.org  Wed Nov  6 09:26:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 09:26:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
 <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
Message-ID: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>

On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>>  Is this posted after the VirtualThreadMount extension event posted?
>>>
>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620
>
>> The JvmtiExport::post_monitor_waited() is called at the line 1801.
>> Does it post the MonitorWaited event for this virtual thread as well?
>>
> That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

Just to add that the 2 extension events (VirtualThreadMount and  VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204

From ihse at openjdk.org  Wed Nov  6 15:21:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:21:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@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 FIXME

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/9b10e74c..de3c773a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29-30

  Stats: 1 line in 1 file changed: 0 ins; 1 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 Nov  6 15:21:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:21:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
Message-ID: <1C4ITw6Oql1qCggf80rAZ73NIjGNwdYQzWHUfb_8LLE=.0140fca3-d921-4ec3-bd82-1f9cf7bb0a31@github.com>

On Tue, 5 Nov 2024 16:28:04 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: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 5820:
> 
>> 5818: }
>> 5819: 
>> 5820: // FIXME
> 
> ???

I apologize this slipped through. It was a marker for myself which I added when searching for code that did _stdcall name mangling operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831227000

From ihse at openjdk.org  Wed Nov  6 15:29:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:29:49 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
Message-ID: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>

On Tue, 5 Nov 2024 08:58:00 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: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 5863:
> 
>> 5861:     return nullptr;
>> 5862:   }
>> 5863: 
> 
> [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.]
> The calculation of `len` is wasting a byte when `lib_name` is null.  The `+2` accounts for the
> terminating `NUL` and the underscore separator between the sym_name part and the lib_name
> part.  That underscore isn't added when there isn't a lib_name part.  I think the simplest fix would
> be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation.  And add some
> commentary.
> 
> This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment
> padding, and it slightly further complicates the calculation.  But additional commentary would still
> be desirable, to guide the next careful reader.  In which case it might be simpler to describe the
> fixed version.
> 
> Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup
> change.

I've created https://bugs.openjdk.org/browse/JDK-8343703 for this, amongst other things.

> src/hotspot/share/include/jvm.h line 1165:
> 
>> 1163: #define AGENT_ONLOAD_SYMBOLS    {"Agent_OnLoad"}
>> 1164: #define AGENT_ONUNLOAD_SYMBOLS  {"Agent_OnUnload"}
>> 1165: #define AGENT_ONATTACH_SYMBOLS  {"Agent_OnAttach"}
> 
> There is more cleanup that can be done here.  These definitions are used as
> array initializers (hence the surrounding curly braces).  They are now always
> singleton, rather than sometimes having 2 elements.  The uses iterate over the
> now always singleton arrays.  Those iterations are no longer needed and could
> be eliminated.  And these macros could be eliminated, using the corresponding
> string directly in each use.  This can all be done as a followup change.

Handled by https://bugs.openjdk.org/browse/JDK-8343703.

> src/java.base/share/native/libjava/NativeLibraries.c line 67:
> 
>> 65:         strcat(jniEntryName, "_");
>> 66:         strcat(jniEntryName, cname);
>> 67:     }
> 
> I would prefer this be directly inlined at the sole call (in findJniFunction),
> to make it easier to verify there aren't any buffer overrun problems. (I don't
> think there are, but looking at this in isolation triggered warnings in my
> head.)
> 
> Also, it looks like all callers of findJniFunction ensure the cname argument
> is non-null. So there should be no need to handle the null case in
> findJniFunction (other than perhaps an assert or something). That could be
> addressed in a followup. (I've already implicitly suggested elsewhere in this
> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
> thing.)

@kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240264
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240942
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831243370

From bpb at openjdk.org  Wed Nov  6 15:39:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Nov 2024 15:39:29 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v3]
In-Reply-To: <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
Message-ID: <ibw5ABgYii_dJ1uyuQnWLBfafA-8XxVdMMmfHVHnNGk=.587d5193-ec6f-4b2b-8dc1-eb580420182b@github.com>

On Wed, 6 Nov 2024 01:31:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343417: Use utimensat or lutimes when not following links

> I think what you have is correct now but it's hard to follow as it's one of 4 sys calls. [...] I realise this is adding to the work on this change but right now it's hard for anyone to touch this method due to the many cases.

It definitely needs reworking but I do not know the details as yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/21886#issuecomment-2460094503

From sspitsyn at openjdk.org  Wed Nov  6 16:00:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 16:00:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
 <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>
Message-ID: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.b0e6bf31-c7dd-4702-ac97-043ed536821e@github.com>

On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So at some point I think we need to figure out how to make them go away  ...

Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.

> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...

The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.

> That's the path a virtual thread will take if pinned. 

Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112

From sspitsyn at openjdk.org  Wed Nov  6 16:34:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 16:34:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
 <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>
Message-ID: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.483b5c46-cc7b-4cd5-80bf-b1462c684d36@github.com>

On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
>> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
>> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.
>
> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
> 
> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.

> but does the specs say the event has to be posted in the context of the vthread?

As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.

> For pop_frame/early_ret checks ...

The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.

> Maybe we could go with this simplified code now and work on it later...

Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
It would be nice to fix a couple of nits though:
 - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
 - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766

From pchilanomate at openjdk.org  Wed Nov  6 17:39:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:39:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without
 Pinning
Message-ID: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@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:
 - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
 - Move load of _lock_id in C2_MacroAssembler::fast_lock
 - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
 - Update comment for _cont_fastpath
 - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
 - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
 - Fixes to JFR metadata.xml
 - Fix return miss prediction in generate_native_entry for riscv
 - Fix s390x failures
 - Add oopDesc::has_klass_gap() check
 - ... and 70 more: https://git.openjdk.org/jdk/compare/751a914b...211c6c81

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: 9914 lines in 246 files changed: 7105 ins; 1629 del; 1180 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 aboldtch at openjdk.org  Wed Nov  6 17:39:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:39:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@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...

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.

Good work! I'll approve the GC related changes.

There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.

Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.

A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.

// the sp of the oldest known interpreted/call_stub frame inside the
// continuation that we know about

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

> 443: 
> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();

Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 

There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

src/hotspot/share/oops/stackChunkOop.cpp line 460:

> 458:     } else {
> 459:       oop value = *reinterpret_cast<oop*>(at);
> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);

Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

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

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;
   }
 ```

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/objectMonitor.inline.hpp line 50:

> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Suggestion:

  assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

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?

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:

> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
> 61:         MONITOR(3, "Monitor held"),
> 62:         CRITICAL_SECTION(4, "In critical section");

Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 

I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930
Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171
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_r1825949756
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254
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_r1810772765
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911
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_r1829464866
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764

From dholmes at openjdk.org  Wed Nov  6 17:39:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:39:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@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...

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

Thanks for those updates.

Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.)

Next batch of comments ...

Updates look good - thanks.

I think I have nothing further in terms of the review process. Great work!

Marked as reviewed by dholmes (Reviewer).

Marked as reviewed by dholmes (Reviewer).

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

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?

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/classfile/javaClasses.cpp line 2107:

> 2105: 
> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
> 2107:   return vthread->long_field(_timeout_offset);

Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

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/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/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:     // frame can't be freezed. Most likely the call_stub or upcall_stub

Suggestion:

    // Frame can't be frozen. Most likely the call_stub or upcall_stub

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?

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

> 1704:     // on _WaitSetLock so it's not profitable to reduce the length of the
> 1705:     // critical section.
> 1706: 

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

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

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/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:           // If currentThread is nullptr we would like to know if the owner

Suggestion:

          // If currentThread is null we would like to know if the owner

src/hotspot/share/services/threadService.cpp line 474:

> 472:           // vthread we never record this as a deadlock. Note: unless there
> 473:           // is a bug in the VM, or a thread exits without releasing monitors
> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.

Suggestion:

          // acquired through JNI, null should imply an unmounted vthread owner.

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.

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/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. ??

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.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768
Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880
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_r1827128518
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043
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_r1810025380
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_r1810027786
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172
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_r1815959203
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_r1811914377
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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622
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_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
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 coleenp at openjdk.org  Wed Nov  6 17:39:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:39:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@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...

I've done a first pass over the first commit and have some comments and questions.

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.

Some more comments and questions on the latest commit, mostly minor.

I've traced through the runtime code (minus calculations for continuations) and found some typos on the way.  Excellent piece of work.

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

Noticed while downloading this that some copyrights need updating.

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/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/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/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 ?  Seems to be used consistently as thread_id in much of the platform code.

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/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/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.

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

> 1548:   assert(!cont.is_empty(), "");
> 1549:   // This is done for the sake of the enterSpecial frame
> 1550:   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/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.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/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

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

> 1012:   assert_mark_word_consistency();
> 1013:   UnlinkAfterAcquire(current, currentNode);
> 1014:   if (is_succesor(current)) clear_succesor();

successor has two 's'.

src/hotspot/share/runtime/objectMonitor.cpp line 1158:

> 1156:     if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) {
> 1157:       assert(_recursions == 0, "invariant");
> 1158:       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.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.

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-2386614214
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570
Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307
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_r1811590155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085
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_r1817407075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425
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_r1823233359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877
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 fbredberg at openjdk.org  Wed Nov  6 17:39:53 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:39:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@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...

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).

I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks!

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: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418
Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086
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 dlong at openjdk.org  Wed Nov  6 17:39:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:39:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@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...

Marked as reviewed by dlong (Reviewer).

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

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).

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 finished looking at this, and it looks good.  Nice work!

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.

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)`?

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");

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());

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?

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?

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?

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?

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?

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?

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.

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()?

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`?

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.

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.

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.

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.

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

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?

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.

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.

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.

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.

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`?

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?

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.

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.

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.

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.

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.

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()`?

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.

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?

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?

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?

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.

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.

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());

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?

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?

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.

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?

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.

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.

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.

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?

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.

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?

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: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245
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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638

From amitkumar at openjdk.org  Wed Nov  6 17:39:59 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 6 Nov 2024 17:39:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <jj6iCskb42eGr6L5b_roCs03SXecaECIHTT5TRMmOHg=.fa6f1075-44c4-467e-b760-fced28ad2499@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...

Hi @pchilano, 

I see couple of failures on s390x, can you apply this patch: 


diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
index f342240f3ca..d28b4579824 100644
--- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
@@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1
 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp1;
@@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
   // If csg succeeds then CR=EQ, otherwise, register zero is filled
   // with the current owner.
   z_lghi(zero, 0);
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
 
   // Store a non-null value into the box.
   z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box);
@@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 
   BLOCK_COMMENT("fast_path_recursive_lock {");
   // Check if we are already the owner (recursive lock)
-  z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above
+  z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above
   z_brne(done); // not a recursive lock
 
   // Current thread already owns the lock. Just increment recursion count.
@@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp2;
@@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg
   // Handle existing monitor.
   bind(object_has_monitor);
 
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
   z_brne(done);
 
   BLOCK_COMMENT("fast_path_recursive_unlock {");
@@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t
 }
 
 void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) {
-  assert_different_registers(obj, box, tmp1, tmp2);
+  assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch);
 
   // Handle inflated monitor.
   NearLabel inflated;
@@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe
     // If csg succeeds then CR=EQ, otherwise, register zero is filled
     // with the current owner.
     z_lghi(zero, 0);
-    z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-    z_csg(zero, Z_R1_scratch, owner_address);
+    z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+    z_csg(zero, Z_R0_scratch, owner_address);
     z_bre(monitor_locked);
 
     // Check if recursive.
-    z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction
+    z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction
     z_brne(slow_path);
 
     // Recursive


CC: @RealLucy

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800

From aph at openjdk.org  Wed Nov  6 17:40:00 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>     * 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.

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.

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 Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647
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 alanb at openjdk.org  Wed Nov  6 17:40:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <ekXIc0jjx_4MlD-GhPzW5S5LA4GARcY2WSXvLmnRl04=.11a33af1-6caf-476f-a30f-38a15fc188d5@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 coleenp at openjdk.org  Wed Nov  6 17:40:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@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.

> 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 Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605
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 mchung at openjdk.org  Wed Nov  6 17:40:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <FkxtznpxqChlt5BT4JAL3tkjv7vJu-QBC7sBeCg8wQc=.a602c21c-088a-4728-bd13-aaf8b348a3bb@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...

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 bpb at openjdk.org  Wed Nov  6 17:40:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <ZjehOI9RwnlCQfoK6WlUYkqoqU3nW6c8f80l0pSZ1YQ=.0a867f4a-3c4e-4aaf-9117-791a34392108@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...

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 pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@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.

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

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

> 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()`.

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

> 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/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.

> 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/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/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.

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

> 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/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.

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

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

Added an overload method.

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

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

> 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().

> 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 Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426
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_r1819592799
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856
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_r1821591143
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264
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_r1823509538
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178
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_r1823511520
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636
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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260

From dlong at openjdk.org  Wed Nov  6 17:40:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@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.

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

>> 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"?

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

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

>> 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 Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967

From michaelm at openjdk.org  Wed Nov  6 17:40:00 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <Q1jPK8TnNv45P679HTgjg5q6q7BtdKvBymZQv4GCAug=.f7b54ea3-c284-4745-b170-d1a4cb9e1758@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...

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 pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
 <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com>
Message-ID: <S0IfxODyOvrNooBjR0lhlgrGg1zHFmID_7LfL0W8uFo=.9da718f1-4d16-4333-a44f-81701e492657@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.

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

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

>> `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 Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898

From alanb at openjdk.org  Wed Nov  6 17:40:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@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 know 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.

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

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

> 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 conflict with the Node in compile.hpp. Just lucky not to run into this in main-line. It comes and goes, depends on changes to header files that are transitively included by the test. I think Johan had planned to change this in main line but it may have got forgotten.

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

> 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.  Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430

From pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@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...

I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test.

I brought some JFR changes from the loom repo that improve the reported reason when pinning.
@mgronlun @egahlin Could any of you review these JFR changes? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@github.com>
Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.bd6692e9-93aa-46cf-b9de-75b06d83dd73@github.com>

On Tue, 5 Nov 2024 01:47:29 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...
>
> I brought some JFR changes from the loom repo that improve the reported reason when pinning.
> @mgronlun @egahlin Could any of you review these JFR changes? Thanks.

> Hi @pchilano,
> 
> I see couple of failures on s390x, can you apply this patch:
> 
Thanks @offamitkumar. Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
Message-ID: <IIT6ZK5VHBwBQs0KkppCGOwgf55SIZk7-HKtZvFfIRQ=.518f21f8-2ddf-4e7c-bec9-1c5862e44fe7@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  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>

On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas <aboldtch 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/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 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/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.

> 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/oops/stackChunkOop.cpp line 445:
> 
>> 443: 
>> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
>> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> 
> Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 
> 
> There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

Good, passed as argument now.

> src/hotspot/share/oops/stackChunkOop.cpp line 460:
> 
>> 458:     } else {
>> 459:       oop value = *reinterpret_cast<oop*>(at);
>> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> 
> Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
> So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

Ok, I just omitted clearing the oop.

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

> 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/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?

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

> 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/objectMonitor.inline.hpp line 50:
> 
>> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
>> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
>> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Suggestion:
> 
>   assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

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_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_r1809753868
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046
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_r1826149674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839
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_r1830229529
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940

From aph at openjdk.org  Wed Nov  6 17:40:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>

On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley <aph 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/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  Wed Nov  6 17:40:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
Message-ID: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
 <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@github.com>
Message-ID: <gGm48Cxs1mgNeICqJxSkVYxDdT4gGogR9QP6rIcrDVQ=.96243863-0f53-42db-a7c5-0b94beb602a0@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 coleenp at openjdk.org  Wed Nov  6 17:40:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <vc7yb0rPrCsvTFxlSjVuCowEFqyXNl89l6Ls2eVYS4g=.dbadfee9-cd55-4fbd-9762-6ef640ca7cd6@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>

On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore <coleenp 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/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/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/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/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.

> 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/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 1550:
> 
>> 1548:   assert(!cont.is_empty(), "");
>> 1549:   // This is done for the sake of the enterSpecial frame
>> 1550:   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/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.

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

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

> 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_r1816658344
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987
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_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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958

From dlong at openjdk.org  Wed Nov  6 17:40:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <jiLbxr6TkMLG8JgH0CHhoJpkggmJZjyxoWVBLU8Frgk=.a7235433-1d61-4ffb-b275-6f934679a94c@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  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long <dlong 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/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 pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
Message-ID: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@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  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
Message-ID: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@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 dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
Message-ID: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
Message-ID: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@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 dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
Message-ID: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
Message-ID: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@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 dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
Message-ID: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo <pchilanomate 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?  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.
>
>> 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.

It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
Message-ID: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>

On Fri, 1 Nov 2024 07:14:35 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.
>
> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

Here's my suggested C2 change:

diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
index d9c77a2f529..1e99db191ae 100644
--- a/src/hotspot/cpu/aarch64/aarch64.ad
+++ b/src/hotspot/cpu/aarch64/aarch64.ad
@@ -3692,14 +3692,13 @@ encode %{
       __ post_call_nop();
     } else {
       Label retaddr;
+      // Make the anchor frame walkable
       __ adr(rscratch2, retaddr);
+      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
       __ lea(rscratch1, RuntimeAddress(entry));
-      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
-      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
       __ blr(rscratch1);
       __ bind(retaddr);
       __ post_call_nop();
-      __ add(sp, sp, 2 * wordSize);
     }
     if (Compile::current()->max_vector_size() > 0) {
       __ reinitialize_ptrue();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
Message-ID: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>

On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.
>
> Here's my suggested C2 change:
> 
> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
> index d9c77a2f529..1e99db191ae 100644
> --- a/src/hotspot/cpu/aarch64/aarch64.ad
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
> @@ -3692,14 +3692,13 @@ encode %{
>        __ post_call_nop();
>      } else {
>        Label retaddr;
> +      // Make the anchor frame walkable
>        __ adr(rscratch2, retaddr);
> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>        __ lea(rscratch1, RuntimeAddress(entry));
> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>        __ blr(rscratch1);
>        __ bind(retaddr);
>        __ post_call_nop();
> -      __ add(sp, sp, 2 * wordSize);
>      }
>      if (Compile::current()->max_vector_size() > 0) {
>        __ reinitialize_ptrue();

Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
@RealFYang I made the equivalent change for riscv, could you verify it's okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069

From fyang at openjdk.org  Wed Nov  6 17:40:02 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
Message-ID: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>

On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Here's my suggested C2 change:
>> 
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
>> @@ -3692,14 +3692,13 @@ encode %{
>>        __ post_call_nop();
>>      } else {
>>        Label retaddr;
>> +      // Make the anchor frame walkable
>>        __ adr(rscratch2, retaddr);
>> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>>        __ lea(rscratch1, RuntimeAddress(entry));
>> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>        __ blr(rscratch1);
>>        __ bind(retaddr);
>>        __ post_call_nop();
>> -      __ add(sp, sp, 2 * wordSize);
>>      }
>>      if (Compile::current()->max_vector_size() > 0) {
>>        __ reinitialize_ptrue();
>
> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
> @RealFYang I made the equivalent change for riscv, could you verify it's okay?

@pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
`hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.

BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
Do you mind adding following small addon change to fix it? Thanks.

diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 84a292242c3..ac28f4b3514 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   if (LockingMode != LM_LEGACY) {
     // Check preemption for Object.wait()
     Label not_preempted;
-    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ beqz(t0, not_preempted);
+    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
+    __ beqz(t1, not_preempted);
     __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ jr(t0);
+    __ jr(t1);
     __ bind(native_return);
     __ restore_after_resume(true /* is_native */);
     // reload result_handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
 <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>
Message-ID: <Z0J2vBm4Z7jT_aibhLEjVlN3tMtVt4kPuxrXg28hRmY=.c14859e0-5fad-4cd9-805c-6a92b4b0a1ac@github.com>

On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
>> @RealFYang I made the equivalent change for riscv, could you verify it's okay?
>
> @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
> `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.
> 
> BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
> Do you mind adding following small addon change to fix it? Thanks.
> 
> diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> index 84a292242c3..ac28f4b3514 100644
> --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
>    if (LockingMode != LM_LEGACY) {
>      // Check preemption for Object.wait()
>      Label not_preempted;
> -    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ beqz(t0, not_preempted);
> +    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> +    __ beqz(t1, not_preempted);
>      __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ jr(t0);
> +    __ jr(t1);
>      __ bind(native_return);
>      __ restore_after_resume(true /* is_native */);
>      // reload result_handler

Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335

From dholmes at openjdk.org  Wed Nov  6 17:40:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@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 coleenp at openjdk.org  Wed Nov  6 17:40:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
 <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com>
Message-ID: <Iauve4e-TfFi91-Hv_DrqLHSnKCNs5bspnsFy8b737w=.ae0f0912-7bc2-4d1a-a734-090861186113@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 dlong at openjdk.org  Wed Nov  6 17:40:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@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.

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

>> 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_r1819586705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
Message-ID: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@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.

> 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_r1819595482
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
 <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@github.com>
Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.b1b308d9-8e8e-4d1d-8cd3-935c637679ab@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 aboldtch at openjdk.org  Wed Nov  6 17:40:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
Message-ID: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@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 rrich at openjdk.org  Wed Nov  6 17:40:03 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>

On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long <dlong 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/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

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

> 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_r1817702223
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994

From coleenp at openjdk.org  Wed Nov  6 17:40:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>

On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley <aph 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/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 pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
Message-ID: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>

On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg <fbredberg 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/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 fbredberg at openjdk.org  Wed Nov  6 17:40:03 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <FmKOCSsujrPLhOUfXlnZeAeUrWiLQLMmseBgvHuWrsA=.88ba6d7c-d61e-4bcb-894e-a66e2327b73b@github.com>

On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley <aph 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/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 Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@github.com>
Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.0465a56a-7cf4-4455-82c6-4097a3f8e456@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 coleenp at openjdk.org  Wed Nov  6 17:40:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>

On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long <dlong 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/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.

> 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_r1819394224
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312

From dlong at openjdk.org  Wed Nov  6 17:40:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
Message-ID: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
Message-ID: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@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 coleenp at openjdk.org  Wed Nov  6 17:40:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
Message-ID: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@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  Wed Nov  6 17:40:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
Message-ID: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
Message-ID: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@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.Object 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  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
 <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@github.com>
Message-ID: <KN4s68yO3KTnPYb3y0eMexToy1B3J9bOQPwDhbuDpk0=.16887faa-af27-4462-b9ae-2d4f1ee1c5f2@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.Object 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 fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
Message-ID: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>

On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 

(PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713

From fbredberg at openjdk.org  Wed Nov  6 17:40:04 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
Message-ID: <PEExBTpPubCYRqoBU8sHuhGn7KxgJhWaRkGXiAJ22zA=.a95a2a94-e81a-4570-83a0-dd3cd9639313@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
Message-ID: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876

From fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>

On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>
> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 

> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

I agree with @pchilano in that we are fine with these places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
Message-ID: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>

On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
>> 
>> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)
>
> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>
I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
 <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>
Message-ID: <B6yKYX170EzYJUUBWPDAOJmNDGNVRsSXi4OBHWmh4TU=.727aef83-4bdb-4bc2-8139-c1f7909ba583@github.com>

On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
>> 
>> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
>> 
>>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
>> 
>> I agree with @pchilano in that we are fine with these places.
>
>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
> 
> Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <LXvYQLMhjGyozdv2SaLbBGAv7rujDnS1jd9JyvUTHBw=.27fe7cc4-a530-4c46-98f3-a45a09f1abc2@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 fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
Message-ID: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>

On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.
>
>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
> 
> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
> 
>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
> 
> I agree with @pchilano in that we are fine with these places.

> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>

On Mon, 28 Oct 2024 01:13:05 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/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.

> 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/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:     // frame can't be freezed. Most likely the call_stub or upcall_stub
> 
> Suggestion:
> 
>     // Frame can't be frozen. Most likely the call_stub or upcall_stub

Fixed.

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

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

Updated comment.

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

> src/hotspot/share/runtime/objectMonitor.cpp line 1706:
> 
>> 1704:     // on _WaitSetLock so it's not profitable to reduce the length of the
>> 1705:     // critical section.
>> 1706: 
> 
> Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

Restored.

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

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

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

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

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

> 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/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:           // If currentThread is nullptr we would like to know if the owner
> 
> Suggestion:
> 
>           // If currentThread is null we would like to know if the owner

Fixed.

> src/hotspot/share/services/threadService.cpp line 474:
> 
>> 472:           // vthread we never record this as a deadlock. Note: unless there
>> 473:           // is a bug in the VM, or a thread exits without releasing monitors
>> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.
> 
> Suggestion:
> 
>           // acquired through JNI, null should imply an unmounted vthread owner.

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`.

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

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

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

> 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_r1819744051
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_r1826154797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851
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_r1817388840
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027
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_r1811596618
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730
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_r1817195731
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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856
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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906
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
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_r1817190381
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312

From dlong at openjdk.org  Wed Nov  6 17:40:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
 <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@github.com>
Message-ID: <E5BoDn6nBa-B8W6bUd-RciLLaEMNTcF4YVT2JlpCXGg=.cc56de01-4821-4250-9b86-f4e2f969e2be@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 dholmes at openjdk.org  Wed Nov  6 17:40:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
Message-ID: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@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 dlong at openjdk.org  Wed Nov  6 17:40:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
 <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@github.com>
Message-ID: <kIzpbt39CsWh1gBz35CCjVl8f7vkM_2dZp84RE0OC_U=.4ceea7be-bcbf-4ba9-872e-c0cb71b47468@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 rrich at openjdk.org  Wed Nov  6 17:40:06 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@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/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/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()`.

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?

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_r1812377293
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <Wz421HivVaSYw32P_FziXYHdelelv3igEJaecq1D0qM=.acbfeb84-fb97-42c1-8221-3f29d3c3a2ab@github.com>

On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber <rrich 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/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  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@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.

>> 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_r1817193493
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
Message-ID: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@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 dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
Message-ID: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
Message-ID: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@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 dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
Message-ID: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.e2d498b3-8477-48a7-be81-b328c592289e@github.com>

On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>> 
>>> 2105: 
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107:   return vthread->long_field(_timeout_offset);
>> 
>> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??
>
> It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

Renamed accessors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772

From dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
 <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@github.com>
Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.7a75db37-1cb9-4256-969d-d532b6cdc8e5@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 alanb at openjdk.org  Wed Nov  6 17:40:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>

On Mon, 4 Nov 2024 02:12:40 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/classfile/javaClasses.cpp line 2107:
> 
>> 2105: 
>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>> 2107:   return vthread->long_field(_timeout_offset);
> 
> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

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

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

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

> 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_r1827219720
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
Message-ID: <O8JULSt20GzECs148szBdunnT7m3Gq1N3MraPGVogm4=.7dcb9fcd-5ee5-4018-bf91-2e095bafe80d@github.com>

On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin <egahlin 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/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> The label should be "Blocking Operation" with a capital "O".
> 
> Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128

From alanb at openjdk.org  Wed Nov  6 17:40:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
Message-ID: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>

On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin <egahlin 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/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
> 
> (Note: The fact that the event is now written in the JVM doesn't determine the category.)

Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229

From egahlin at openjdk.org  Wed Nov  6 17:40:07 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@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/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:

https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html

(Note: The fact that the event is now written in the JVM doesn't determine the category.)

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

The label should be "Blocking Operation" with a capital "O".

Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
 <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>
Message-ID: <FST2J8IQ3-HRqwpZqe44YLVavuGNcakXyrIKmnieBU4=.2ab8bece-5b62-4c69-8d58-ca7d046f2651@github.com>

On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 160:
>> 
>>> 158: 
>>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
>> 
>> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
>> 
>> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
>> 
>> (Note: The fact that the event is now written in the JVM doesn't determine the category.)
>
> Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765

From pchilanomate at openjdk.org  Wed Nov  6 17:40:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
Message-ID: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>

On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn <sspitsyn 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/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.

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

> src/hotspot/share/runtime/continuation.cpp line 134:
> 
>> 132:   return true;
>> 133: }
>> 134: #endif // INCLUDE_JVMTI
> 
> Could you, please, consider the simplification below?
> 
> 
> #if INCLUDE_JVMTI
> // return true if started vthread unmount
> bool jvmti_unmount_begin(JavaThread* target) {
>   assert(!target->is_in_any_VTMS_transition(), "must be");
> 
>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>   // be installed in start_VTMS_transition() so we need to check it here.
>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>     JvmtiThreadState* state = target->jvmti_thread_state();
>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>       return false;
>     }
>   }
>   // Don't preempt in case there is an async exception installed since
>   // we would incorrectly throw it during the unmount logic in the carrier.
>   if (target->has_async_exception_condition()) {
>     return false;
>   }
>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>   } else {
>     target->set_is_in_VTMS_transition(true);
>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>   }
>   return false;
> }
> 
> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>   if (target->is_in_VTMS_transition()) {
>     // We caught target at the end of a mount transition.
>     return false;
>   }
>   return true;
> }
> #endif // INCLUDE_JVMTI
> ...
> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>     return false;
>   }
>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
> }
> ...
> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>   verify_preempt_preconditions(target, continuation);
> 
>   if (LockingMode == LM_LEGACY) {
>     return freeze_unsupported;
>   }
>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>     return freeze_pinned_native;
>   }
>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>   log_trace(continuations, preempt)("try_preempt: %d", res);
>   return res;
> }
> 
> 
> The following won't be needed:
> 
> target->set_pending_jvmti_unmou...

Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

>  Is this posted after the VirtualThreadMount extension event posted?
>
It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909

From yzheng at openjdk.org  Wed Nov  6 17:40:07 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@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/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 sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@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/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 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.

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.

src/hotspot/share/runtime/continuation.cpp line 134:

> 132:   return true;
> 133: }
> 134: #endif // INCLUDE_JVMTI

Could you, please, consider the simplification below?


#if INCLUDE_JVMTI
// return true if started vthread unmount
bool jvmti_unmount_begin(JavaThread* target) {
  assert(!target->is_in_any_VTMS_transition(), "must be");

  // Don't preempt if there is a pending popframe or earlyret operation. This can
  // be installed in start_VTMS_transition() so we need to check it here.
  if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
    JvmtiThreadState* state = target->jvmti_thread_state();
    if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
      return false;
    }
  }
  // Don't preempt in case there is an async exception installed since
  // we would incorrectly throw it during the unmount logic in the carrier.
  if (target->has_async_exception_condition()) {
    return false;
  }
  if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
    JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
  } else {
    target->set_is_in_VTMS_transition(true);
    // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
  }
  return false;
}

static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
  if (target->is_in_VTMS_transition()) {
    // We caught target at the end of a mount transition.
    return false;
  }
  return true;
}
#endif // INCLUDE_JVMTI
...
static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
  assert(java_lang_VirtualThread::is_instance(vthread), "");
  if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
    return false;
  }
  return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
}
...
int Continuation::try_preempt(JavaThread* target, oop continuation) {
  verify_preempt_preconditions(target, continuation);

  if (LockingMode == LM_LEGACY) {
    return freeze_unsupported;
  }
  if (!is_safe_vthread_to_preempt(target, target->vthread())) {
    return freeze_pinned_native;
  }
  JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
  int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
  log_trace(continuations, preempt)("try_preempt: %d", res);
  return res;
}


The following won't be needed:

target->set_pending_jvmti_unmount_event(true);

jvmtiThreadState.cpp:

+  if (thread->pending_jvmti_unmount_event()) {
+    assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted");
+    JvmtiExport::post_vthread_unmount(vthread);
+    thread->set_pending_jvmti_unmount_event(false);
+  }


As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual.

src/hotspot/share/runtime/objectMonitor.cpp line 1643:

> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);

We post a JVMTI `MonitorWaited` event here for a virtual thread.
A couple of questions on this:
- Q1: Is this posted after the `VirtualThreadMount` extension event posted?
         Unfortunately, it is not easy to make this conclusion.
- Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
          Does it post the `MonitorWaited` event for this virtual thread as well?
          If not, then it is not clear how posting for virtual thread is avoided.

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

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
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@github.com>
Message-ID: <K5riEGYhTK3b9yrDmiB_hU9eUxZ5SstOxTPMSq0_VOw=.ab39fe6f-a308-4097-a3d8-cd99fe2b08e5@github.com>

On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng <yzheng 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/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 fbredberg at openjdk.org  Wed Nov  6 17:40:09 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
Message-ID: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@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  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
 <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>
Message-ID: <FJEpZFaGxULmsFhOGyiaLRoIWxL2o9bKBNbo4LWqlrs=.1d735b40-7e9a-41f7-ae49-dc4bf1a0549b@github.com>

On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> 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.
>
> This code in `StackChunkAllocator::initialize` mimics the clearing code in:
> 
> void MemAllocator::mem_clear(HeapWord* mem) const {
>   assert(mem != nullptr, "cannot initialize null object");
>   const size_t hs = oopDesc::header_size();
>   assert(_word_size >= hs, "unexpected object size");
>   oopDesc::set_klass_gap(mem, 0);
>   Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
> }
> 
> 
> but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:
> 
>   if (oopDesc::has_klass_gap()) {
>     oopDesc::set_klass_gap(mem, 0);
>   }
> 
> 
> So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

Thanks for confirming. I added the check here which I think should cover any merge order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
Message-ID: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>

On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 134:
>> 
>>> 132:   return true;
>>> 133: }
>>> 134: #endif // INCLUDE_JVMTI
>> 
>> Could you, please, consider the simplification below?
>> 
>> 
>> #if INCLUDE_JVMTI
>> // return true if started vthread unmount
>> bool jvmti_unmount_begin(JavaThread* target) {
>>   assert(!target->is_in_any_VTMS_transition(), "must be");
>> 
>>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>>   // be installed in start_VTMS_transition() so we need to check it here.
>>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>>     JvmtiThreadState* state = target->jvmti_thread_state();
>>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>>       return false;
>>     }
>>   }
>>   // Don't preempt in case there is an async exception installed since
>>   // we would incorrectly throw it during the unmount logic in the carrier.
>>   if (target->has_async_exception_condition()) {
>>     return false;
>>   }
>>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>>   } else {
>>     target->set_is_in_VTMS_transition(true);
>>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>>   }
>>   return false;
>> }
>> 
>> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>>   if (target->is_in_VTMS_transition()) {
>>     // We caught target at the end of a mount transition.
>>     return false;
>>   }
>>   return true;
>> }
>> #endif // INCLUDE_JVMTI
>> ...
>> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>>     return false;
>>   }
>>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
>> }
>> ...
>> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>>   verify_preempt_preconditions(target, continuation);
>> 
>>   if (LockingMode == LM_LEGACY) {
>>     return freeze_unsupported;
>>   }
>>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>>     return freeze_pinned_native;
>>   }
>>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>>   log_trace(con...
>
> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.

[1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>> 
>>> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
>>> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);
>> 
>> We post a JVMTI `MonitorWaited` event here for a virtual thread.
>> A couple of questions on this:
>> - Q1: Is this posted after the `VirtualThreadMount` extension event posted?
>>          Unfortunately, it is not easy to make this conclusion.
>> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
>>           Does it post the `MonitorWaited` event for this virtual thread as well?
>>           If not, then it is not clear how posting for virtual thread is avoided.
>
>>  Is this posted after the VirtualThreadMount extension event posted?
>>
> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

> The JvmtiExport::post_monitor_waited() is called at the line 1801.
> Does it post the MonitorWaited event for this virtual thread as well?
>
That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475

From stefank at openjdk.org  Wed Nov  6 17:40:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
Message-ID: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>

On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

This code in `StackChunkAllocator::initialize` mimics the clearing code in:

void MemAllocator::mem_clear(HeapWord* mem) const {
  assert(mem != nullptr, "cannot initialize null object");
  const size_t hs = oopDesc::header_size();
  assert(_word_size >= hs, "unexpected object size");
  oopDesc::set_klass_gap(mem, 0);
  Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
}


but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:

  if (oopDesc::has_klass_gap()) {
    oopDesc::set_klass_gap(mem, 0);
  }


So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227

From pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@github.com>
Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.f139275c-bc20-4f0b-9eef-c979c3e83e12@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  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
Message-ID: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@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 coleenp at openjdk.org  Wed Nov  6 17:40:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.60f00ea4-6466-4a9d-b27d-0d657b0a6fb5@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 1550:
>> 
>>> 1548:   assert(!cont.is_empty(), "");
>>> 1549:   // This is done for the sake of the enterSpecial frame
>>> 1550:   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 sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
Message-ID: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>

On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
>> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
>> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.
>
> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
> 
> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.

> but does the specs say the event has to be posted in the context of the vthread?

As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.

> For pop_frame/early_ret checks ...

The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.

> Maybe we could go with this simplified code now and work on it later...

Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
It would be nice to fix a couple of nits though:
 - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
 - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766

From sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
Message-ID: <FKZnn7aT8nPcZxjsPU2a96efMUA2BkOBGXQhZ4KIlR4=.cc0d07d1-c07e-4641-8c27-cb065a202297@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
 <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@github.com>
Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.4428db89-23a9-4968-878d-c2427ee67622@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 alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>

On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber <rrich 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 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 Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>

On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas <aboldtch 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.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).

> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
> 
>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>> 61:         MONITOR(3, "Monitor held"),
>> 62:         CRITICAL_SECTION(4, "In critical section");
> 
> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
> 
> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.

Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
Message-ID: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@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 alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
Message-ID: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@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 aboldtch at openjdk.org  Wed Nov  6 17:40:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
 <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@github.com>
Message-ID: <Q4NNfZ8Vuzy9966oDBrXA3pf4818J5MEL13_l_KLmzQ=.63f24f0a-9304-4bf9-98bf-a70928b4d130@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 dholmes at openjdk.org  Wed Nov  6 17:40:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@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/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.

>> 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` ?

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

>> 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. ???

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

>> 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_r1818239594
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.70199a12-d9cd-4a85-86e1-2dbdaf474300@github.com>

On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore <coleenp 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.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 sspitsyn at openjdk.org  Wed Nov  6 17:40:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
Message-ID: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>

On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So at some point I think we need to figure out how to make them go away  ...

Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.

> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...

The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.

> That's the path a virtual thread will take if pinned. 

Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
 <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>
Message-ID: <uhUjIm6NwTlveCt80zVVVMHSs2D2aVRo0oGpZfuiKyk=.32dc9e94-a405-4fe5-872e-c9e5762d02ba@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 alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
Message-ID: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>

On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>>  Is this posted after the VirtualThreadMount extension event posted?
>>>
>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620
>
>> The JvmtiExport::post_monitor_waited() is called at the line 1801.
>> Does it post the MonitorWaited event for this virtual thread as well?
>>
> That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

Just to add that the 2 extension events (VirtualThreadMount and  VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
Message-ID: <Z-POFV3noL0adSkJwHIfc-RbkfBedii0V1qRp-WQ6Ws=.78c0709c-fc26-4804-ac21-1adea8356c8f@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.

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

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

>> 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_r1815697784
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921

From coleenp at openjdk.org  Wed Nov  6 17:40:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <mHKxi5OLZX0oPMqn6app9G5OQcbaOYlcHvumIufOXZQ=.daf4b060-ef66-4034-9e46-def2136b81c5@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.

>> 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_r1817420867
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558

From pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
 <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>
Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.0f1297b9-be4e-4fb9-b34d-4db86ad9a7f8@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 rrich at openjdk.org  Wed Nov  6 17:40:11 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>

On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber <rrich 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/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 dholmes at openjdk.org  Wed Nov  6 17:40:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
Message-ID: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
Message-ID: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
Message-ID: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@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  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@github.com>
Message-ID: <gLdoEBbkdZ34VkSGPRJ9GVsSE3guDPf_s8Rk0eiv6N8=.3f921a6c-ffb1-4cbf-9a5b-5afbd747b177@github.com>

On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson <stefank 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/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  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
 <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@github.com>
Message-ID: <jY7WaK5NmmdDNXECTw7ByGpZ-QFceabiNhX5fucWL_E=.ef9c3659-88c3-4e87-93b0-15361ba0a96c@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 dholmes at openjdk.org  Wed Nov  6 17:40:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>

On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long <dlong 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/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 stefank at openjdk.org  Wed Nov  6 17:40:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@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/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 dholmes at openjdk.org  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
 <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@github.com>
Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.ec5ff767-4b75-40ab-b40c-1579907b978a@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  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
Message-ID: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@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 coleenp at openjdk.org  Wed Nov  6 17:40:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
Message-ID: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@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 coleenp at openjdk.org  Wed Nov  6 17:40:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
Message-ID: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@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 alanb at openjdk.org  Wed Nov  6 17:40:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
Message-ID: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@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.

>> 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_r1812537648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960

From alanb at openjdk.org  Wed Nov  6 17:40:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@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.

>> 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_r1814517084
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426

From pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
Message-ID: <v_7OhzC9sq5rI3jGQjn-W8sPfuqFRlaFWPwvxylxDYM=.e6f250ff-e193-4bca-b23b-ce79633376d2@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 dholmes at openjdk.org  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
Message-ID: <uhNEFqOmOPAUXR5vCaSiMeOvh23OjcpBiUgxjZ5PByU=.c3df6add-a985-422b-bb57-e236e8fb1f40@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  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@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` ?

>> 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_r1811937674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473

From dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
Message-ID: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@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 alanb at openjdk.org  Wed Nov  6 17:40:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
 <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIY
 rMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@github.com>
Message-ID: <bIj9x7QeQeCoCgHy7PkpwOy0SLdF2lRnZ8oKN7yjILk=.b468afba-a5cc-467d-9cbd-a8ed5aade243@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.

Update: The temporary transitions are now removed in the fibers branch (loom repo). This removes the switchToCarrierThread and switchToVirtualThread methods, and removes the need to introduce setCurrentLockId that is hard to explain in the discussions here. Need to decide if we should include it in this PR or try to do it before or after.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
Message-ID: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@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 dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
Message-ID: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@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  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
Message-ID: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@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 dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
Message-ID: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
Message-ID: <cbf7sd9t-JRpuKIcvoZXbga78_Uwu_mqHYxoto2prGs=.6bf41cae-c413-490c-8ae5-7a676986524c@github.com>

On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

Added comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929

From aturbanov at openjdk.org  Wed Nov  6 17:40:13 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@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 pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
Message-ID: <eQsNuW1dYTC5Jth_rKACj76kGFv3ShNY0hP525XOIM8=.c45f0843-0844-4eaf-80f1-5715dd6520f6@github.com>

On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

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

Brought the comment from the loom repo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@github.com>
Message-ID: <wr2gUUNCp_fXQM_ggvjcOSk72PpT3vWBYDmeoL1Bsog=.0dd96592-8976-4522-899a-9bb3dc7d9231@github.com>

On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov <aturbanov 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...
>
> 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 pchilanomate at openjdk.org  Wed Nov  6 17:52:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:52:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>

On Wed, 6 Nov 2024 06:36:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
> 
> ```
> // the sp of the oldest known interpreted/call_stub frame inside the
> // continuation that we know about
> ```
>
Updated comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2460396452

From pchilanomate at openjdk.org  Wed Nov  6 17:53:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:53:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
Message-ID: <4EGJTS9LsdYLK3ecIsExhUZaQupaES8wASP95dS88Cc=.3646b0fe-6e6c-4884-b37f-08360f8e144b@github.com>

On Mon, 4 Nov 2024 07:59:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
>> 
>>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>>> 61:         MONITOR(3, "Monitor held"),
>>> 62:         CRITICAL_SECTION(4, "In critical section");
>> 
>> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
>> 
>> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.
>
> That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.
> 
> Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

These have been updated with the latest JFR changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831465256

From tprinzing at openjdk.org  Wed Nov  6 18:35:32 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 6 Nov 2024 18:35:32 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
 <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>
Message-ID: <yVdfC0Ppn2f0s6M3teSgz3BLizzZgQSCmmN5_sPkQkc=.ba8b05e1-2f49-483f-85e0-0831d1b97d8f@github.com>

On Wed, 6 Nov 2024 07:31:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggested changes
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> I assume you didn't mean to change that.

Not sure how that happened, but I'll fix it

> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106:
> 
>> 104: 
>> 105:                 try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) {
>> 106:                     addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket()));
> 
> This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded.

yes, testing still to be done

> test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108:
> 
>> 106:                 try (Socket s = new Socket()) {
>> 107:                     s.connect(ss.getLocalSocketAddress());
>> 108:                     addExpectedEvent(IOEvent.createSocketConnectEvent(s));
> 
> This is Socket.connect success case, I assume we'll need a test for fail case too.

yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831527507
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529879
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529362

From pchilanomate at openjdk.org  Wed Nov  6 19:40:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@github.com>
Message-ID: <79vVMnHrSZ9MEDcn0UzBYaPJKz63XZ3a7Qn4N0i-pa8=.adbe56c4-4a73-4015-b364-0196f1a4a75a@github.com>

On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

So we use the os thread id when INCLUDE_JFR is not defined, but in that case we never actually post JFR events. So these _previous_owner_tid/_notifier_tid will be unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831592617

From pchilanomate at openjdk.org  Wed Nov  6 19:40:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <EOwH-8BGyV4XLxc63jWvTHTNiWhowp0oLqacwI-5_Os=.e1c144a2-30ce-49bf-8589-931b150ca095@github.com>

On Tue, 29 Oct 2024 02:09:24 GMT, Dean Long <dlong 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/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`?

I think `trust_fp` would be confusing because at this point rfp will have an invalid value and we don't want to use it to restore sp, i.e. we should not trust fp. And `after_resume` wouldn't always apply since we don't always preempt. The `use_pop` name was copied form x64, but I think it's still fine here. We also have the comment right below this line which explains why we don't want to use `leave()` and instead pop the top words from the stack.

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

I moved it before `movq(scrReg, tmpReg)` since we need `boxReg` above, but I don't think this will change anything.

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

Changed to use boolean `is_top_frame`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831594384
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831597325
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831599268

From pchilanomate at openjdk.org  Wed Nov  6 19:40:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
Message-ID: <ZfWP6cjSC8ObaZ0mNXei9U7I83oQdlk9nhxSOjporZU=.cd529cda-8caa-4358-95d2-1430d546b783@github.com>

On Sat, 26 Oct 2024 05:39:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.  Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue.

I added the test to `test/jdk/ProblemList-Xcomp.txt` instead with a reference to 8332028.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831604339

From kbarrett at openjdk.org  Wed Nov  6 21:27:59 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 6 Nov 2024 21:27:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <rVJXGo-DF04qPDC5s93gZktZ41429-h2ZNFRCSERbzI=.86b0f46c-62a0-4f4d-8af7-c05ef0dd511a@github.com>

On Wed, 6 Nov 2024 15:21:10 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:
> 
>   Remove FIXME

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2419454529

From kbarrett at openjdk.org  Wed Nov  6 21:28:00 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 6 Nov 2024 21:28:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
 <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
Message-ID: <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>

On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/native/libjava/NativeLibraries.c line 67:
>> 
>>> 65:         strcat(jniEntryName, "_");
>>> 66:         strcat(jniEntryName, cname);
>>> 67:     }
>> 
>> I would prefer this be directly inlined at the sole call (in findJniFunction),
>> to make it easier to verify there aren't any buffer overrun problems. (I don't
>> think there are, but looking at this in isolation triggered warnings in my
>> head.)
>> 
>> Also, it looks like all callers of findJniFunction ensure the cname argument
>> is non-null. So there should be no need to handle the null case in
>> findJniFunction (other than perhaps an assert or something). That could be
>> addressed in a followup. (I've already implicitly suggested elsewhere in this
>> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
>> thing.)
>
> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.

The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here.  The second part,
cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm
okay with being in a followup.  I guess I can live with the first part being in that followup too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831728737

From pchilanomate at openjdk.org  Thu Nov  7 00:38:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:38:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@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:

  Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/211c6c81..37e30171

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: 108 lines in 7 files changed: 65 ins; 33 del; 10 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 Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
Message-ID: <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>

On Thu, 7 Nov 2024 00:37:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.
>
>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>>
> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.

> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>
Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898891

From pchilanomate at openjdk.org  Thu Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
Message-ID: <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>

On Wed, 6 Nov 2024 16:31:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
>> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
>> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
>> 
>> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629
>
> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.
> 
>> but does the specs say the event has to be posted in the context of the vthread?
> 
> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.
> 
>> For pop_frame/early_ret checks ...
> 
> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
> 
>> Maybe we could go with this simplified code now and work on it later...
> 
> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
> It would be nice to fix a couple of nits though:
>  - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
>  - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898126

From pchilanomate at openjdk.org  Thu Nov  7 00:43:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
 <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
Message-ID: <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>

On Thu, 7 Nov 2024 00:38:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>>>
>> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.
>
>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>>
> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?

> the function is_vthread_safe_to_preempt() does not need the vthread parameter
> 
Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899049

From pchilanomate at openjdk.org  Thu Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
Message-ID: <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>

On Thu, 7 Nov 2024 00:37:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.
>> 
>>> but does the specs say the event has to be posted in the context of the vthread?
>> 
>> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.
>> 
>>> For pop_frame/early_ret checks ...
>> 
>> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>> 
>>> Maybe we could go with this simplified code now and work on it later...
>> 
>> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
>> It would be nice to fix a couple of nits though:
>>  - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
>>  - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter
>
> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.

> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>
The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898439

From pchilanomate at openjdk.org  Thu Nov  7 00:43:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
 <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
Message-ID: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>

On Wed, 6 Nov 2024 15:57:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix.
>
If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899882

From amitkumar at openjdk.org  Thu Nov  7 08:47:14 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 7 Nov 2024 08:47:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
Message-ID: <8WsQTNy83zv4Z7kD6SPo60kURL1EFe3ZMbD4QCqo3II=.3895ed74-7940-436a-aff2-f7aeafbef2b3@github.com>

On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good work! I'll approve the GC related changes.
>> 
>> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.
>> 
>> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.
>> 
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> ```
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>> ```
>>
> Updated comment.

@pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes.

One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. 

[CancelTimerWithContention.log](https://github.com/user-attachments/files/17658594/CancelTimerWithContention.log)

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461640546

From alanb at openjdk.org  Thu Nov  7 09:43:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 09:43:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
Message-ID: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>

On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good work! I'll approve the GC related changes.
>> 
>> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.
>> 
>> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.
>> 
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> ```
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>> ```
>>
> Updated comment.

> @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes.
> 
> One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x.

We added this test to provoke contention on the delay queues, lots of timed-Object.wait with notification before the timeout is reached. This code is not used when running with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuation. In that execution mode, each virtual thread is backed by a platform/native thread and in this test it will ramp up 10_000 virtual threads. The output in your log suggests it gets to ~4700 threads before the jtreg timeout kicks in. It might be that when you run the test on its own that there is enough resources for the test to pass, but not enough resources (just too slow) when competing with other tests.

I think we can add `@requires vm.continuations` to this test. It's not useful to run with the alternative virtual thread implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461756432

From amitkumar at openjdk.org  Thu Nov  7 09:49:12 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 7 Nov 2024 09:49:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
 <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
Message-ID: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>

On Thu, 7 Nov 2024 09:40:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation.

Sure, that sounds ok. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461768715

From dfuchs at openjdk.org  Thu Nov  7 10:25:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Nov 2024 10:25:48 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <HEatBbxojCf_pdp6huYY8ehSoDPC2fX-2mzy-kh99tA=.fa421c23-9fdd-4b19-9274-18d2247bdd26@github.com>

On Wed, 6 Nov 2024 00:15:44 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

The code changes look reasonable to me. I had to re-read the documentation of `finishConnect` to get to that point. I mistakenly thought that this method was reserved for the fully non blocking case. I hadn't realised you could start connect() in non blocking mode and finish it in blocking mode... Thanks @AlanBateman for the thorough review of all these odd cases.

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

PR Review: https://git.openjdk.org/jdk/pull/21528#pullrequestreview-2420545416

From shade at openjdk.org  Thu Nov  7 12:12:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Nov 2024 12:12:01 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
Message-ID: <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>

On Wed, 6 Nov 2024 00:56: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:
>> 
>>   fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 510:
> 
>> 508: // Thread start routine for all newly created threads.
>> 509: // Called with the associated Thread* as the argument.
>> 510: static unsigned thread_native_entry(void* t) {
> 
> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

Not sure why this comment was marked as "Resolved". I have the same question here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832573434

From shade at openjdk.org  Thu Nov  7 12:18:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Nov 2024 12:18:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>

On Wed, 6 Nov 2024 15:21:10 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:
> 
>   Remove FIXME

I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2420814976

From jwaters at openjdk.org  Thu Nov  7 12:18:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 7 Nov 2024 12:18:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>
Message-ID: <tS1vWH4y8eWktyKyl4SSRdmz-g-WlQtjcHGggdbLD_Y=.7a9eda40-4d5f-458f-95cf-bd65f4623c2c@github.com>

On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 510:
>> 
>>> 508: // Thread start routine for all newly created threads.
>>> 509: // Called with the associated Thread* as the argument.
>>> 510: static unsigned thread_native_entry(void* t) {
>> 
>> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170
>
> Not sure why this comment was marked as "Resolved". I have the same question here.

@shipilev See addressing comments below:

> https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170
> On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.






> To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832581212

From ihse at openjdk.org  Thu Nov  7 13:00:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Nov 2024 13:00:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <VMSSoQiOvCT10eG-TxugJELfCwvPJGH5Ms4mEPsWpEk=.b2cc32e1-93dd-4626-9aaf-561a19255bac@github.com>

On Thu, 7 Nov 2024 12:16:23 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:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish.

Removing dead code like this is both a bit of an iterative process ("oh, now that we removed X, we can also remove Y"), and a bit of a judgement call ("now that `JNICALL` is not needed,we can remove it"). Sometimes it is not clear where to draw the line. Personally, I'm mostly interested in getting rid of all the junk in the build system; all the rest is just stuff I do as a "community service" to avoid having stuff laying around. (And I did it, under the (apparently na?ve) assumption that this would not require that much extra work :-), coupled with the (more cynical) assumption that if I did not do this, nothing would really happen on this front...)

I personally do think that removing the obsolete `_stdcall` is "provably, uncontroversially, visibly safe". But then again, it's not me who is going to have to chase the future bugs, so I respect your opinion.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462174907

From stuefe at openjdk.org  Thu Nov  7 15:28:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Nov 2024 15:28:05 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <6qzIK_QQ2Rs5deO4jIyicr7ob4CZCg7ajBnbEd9vCFU=.6fc95a24-9f01-4e61-bb21-442720c53437@github.com>

On Thu, 7 Nov 2024 12:16:23 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:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev @magicus Okay but where do we draw the line? Because then we also need to keep the code that takes care of x86 calling convention name mangling.

[Microsoft states](https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170) "On ARM and x64 processors, __stdcall is accepted and *ignored by the compiler*; on ARM and x64 architectures, by convention, arguments are passed in registers 
when possible, and subsequent arguments are passed on the stack."

Similar statements can be found in the MSDN documentation for __cdecl and __fastcall.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462517302

From alanb at openjdk.org  Thu Nov  7 17:14:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 17:14:47 GMT
Subject: RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS [v3]
In-Reply-To: <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
 <UrziCbzKVtFW95IHYsJz361szEP2NFoXbYQj_Kk357w=.8830a674-a338-4c00-a9f7-37602bd77c1e@github.com>
Message-ID: <ENt5ChVPs5p6vkgM8mEVwg2UyujIJmcALSbrVSH-T7Q=.c43d2e21-679c-4390-a1f3-887280c52360@github.com>

On Wed, 6 Nov 2024 01:31:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343417: Use utimensat or lutimes when not following links

Discussed with Brian about some refactoring setTimes to make it more maintainable, and maybe drop the use of methods that only support micro seconds precision The AIX port may hold us back, not sure. So approving for now, there will be cleanup to follow.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21886#pullrequestreview-2421637637

From bpb at openjdk.org  Thu Nov  7 17:21:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Nov 2024 17:21:47 GMT
Subject: Integrated: 8343417: (fs) BasicFileAttributeView.setTimes uses
 microsecond precision with NOFOLLOW_LINKS
In-Reply-To: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
References: <5njcaqmrWBjastxZca2JkiBFhF18k55K0-a6ic0vM-Q=.dbb9ad6f-2171-49aa-b3e5-d5ac463b20fb@github.com>
Message-ID: <mzJCZbrtomuFMIGj9wvKn9qUbhZ22EZirEQXSNkWr4Y=.eb05e22d-2793-4b5f-9172-2f130a1193aa@github.com>

On Mon, 4 Nov 2024 19:30:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add support for setting the last access and last modification times of symbolic links with nanosecond precision on Linux where the system call `utimensat(2)` is available.

This pull request has now been integrated.

Changeset: 56c588b4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56c588b4e88d779cd5c5f67e7bfb4e1641eb9c25
Stats:     145 lines in 5 files changed: 120 ins; 4 del; 21 mod

8343417: (fs) BasicFileAttributeView.setTimes uses microsecond precision with NOFOLLOW_LINKS

Reviewed-by: alanb

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

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

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
Message-ID: <RGAabYiTSOR77XDt_hdE_eTifrzPya410sFk8nrcI8M=.84db63f4-dcaf-4f41-862c-19da134eaa65@github.com>

On Thu, 7 Nov 2024 00:38:18 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:
> 
>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

Thank you for updates! Looks good.
Overall, it is a great job!

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104:

> 102: 
> 103:     err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr);
> 104:     check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call");

Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here.
Also, the `methodName` is better to deallocate with the `deallocate() function.
The same is in the `VirtualThreadMount` callback.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2421828032
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833167652

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
 <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
 <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>
Message-ID: <EyOSVALfmNhRf93TufYKRwteCZIMRF6ugR6FlXYIhFA=.9ab87aa9-ec41-46bd-aaf3-65b634b1aa51@github.com>

On Thu, 7 Nov 2024 00:38:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>>>
>> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?
>
>> the function is_vthread_safe_to_preempt() does not need the vthread parameter
>> 
> Removed.

Thank you for the update! It looks okay to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833168776

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
 <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
 <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>
Message-ID: <8fsvkr2uAamrF-VvR5mNHGF4NF_FJkgMDzxLeVh1wNs=.54597efe-cc91-426d-ae86-f13d20a1f889@github.com>

On Thu, 7 Nov 2024 00:40:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> So at some point I think we need to figure out how to make them go away  ...
>> 
>> Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.
>> 
>>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...
>> 
>> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.
>> 
>>> That's the path a virtual thread will take if pinned. 
>> 
>> Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.
>
>> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix.
>>
> If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit.

Thank you for the explanations and update. The update looks okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833171024

From sspitsyn at openjdk.org  Thu Nov  7 18:38:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:38:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
Message-ID: <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>

On Thu, 7 Nov 2024 00:38:18 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:
> 
>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

src/hotspot/share/prims/jvmtiThreadState.cpp line 2:

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

Nit: No need in the copyright update anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833174843

From kbarrett at openjdk.org  Thu Nov  7 18:42:02 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 7 Nov 2024 18:42:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <3Rg6yosMIl2HdD2FNR-dPM8dSWZiIS3irKW0uOxNnh8=.91ba8741-d3fb-4ecd-9651-325d4f06f9ca@github.com>

On Thu, 7 Nov 2024 12:16:23 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:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

> @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish.

To be clear, I wished it had been done as a separate followup, but reviewed it here all the same, in the interest of
limiting review and testing churn.  If you back it out, that will be more churn that I don't think is particularly
beneficial.  I'll go along with whatever @magicus and @shipilev and @tstuefe decide to do about it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462963330

From pchilanomate at openjdk.org  Thu Nov  7 19:15:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:15:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@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 with a new target base due to a merge or a rebase. The pull request now contains 84 commits:

 - Use get_method_name + copyright revert in jvmtiThreadState.cpp
 - Merge branch 'master' into JDK-8338383
 - Add @requires vm.continuations to CancelTimerWithContention.java
 - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
 - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
 - Move load of _lock_id in C2_MacroAssembler::fast_lock
 - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
 - Update comment for _cont_fastpath
 - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
 - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
 - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a

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

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02
  Stats: 9939 lines in 247 files changed: 7131 ins; 1629 del; 1179 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 Nov  7 19:20:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:20:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
 <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>
Message-ID: <HOfgPDSBY_Ezl9zJTecCVtg4yoCx4rC7XIyKo-4mXgM=.54f4a11a-39b8-4e8a-9ee5-d31778fce314@github.com>

On Thu, 7 Nov 2024 18:32:14 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:
>> 
>>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Nit: No need in the copyright update anymore.

Fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104:
> 
>> 102: 
>> 103:     err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr);
>> 104:     check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call");
> 
> Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here.
> Also, the `methodName` is better to deallocate with the `deallocate() function.
> The same is in the `VirtualThreadMount` callback.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833226416
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833225816

From pchilanomate at openjdk.org  Thu Nov  7 19:24:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:24:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
 <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
 <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>
Message-ID: <uEhEIQqZZyIk7CeXTIfcnQbT5W8Lwg_PDk0x3QGa-vo=.af020b96-7245-4800-91bf-12a3380ab85e@github.com>

On Thu, 7 Nov 2024 09:45:40 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> > I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation.
> 
> Sure, that sounds ok. Thanks.
>
Added `@requires vm.continuations` to the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2463035166

From dholmes at openjdk.org  Fri Nov  8 02:16:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 02:16:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>

On Wed, 6 Nov 2024 15:21:10 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:
> 
>   Remove FIXME

Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:

https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170

I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463619091

From amenkov at openjdk.org  Fri Nov  8 02:38:17 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Nov 2024 02:38:17 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
Message-ID: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>

On Fri, 8 Nov 2024 02:13:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
> 
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
> 
> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

In the page you mentioned:

 Format of a C decorated name
The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463636430

From sspitsyn at openjdk.org  Fri Nov  8 03:05:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Nov 2024 03:05:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@github.com>
Message-ID: <-R7NADC_veb_n80hbfTME54iuMOvSj38dfBrT0KJQOw=.9345dfb0-58bd-4485-b92a-8c79b9114d25@github.com>

On Thu, 7 Nov 2024 19:15:50 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 with a new target base due to a merge or a rebase. The pull request now contains 84 commits:
> 
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
>  - Move load of _lock_id in C2_MacroAssembler::fast_lock
>  - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
>  - Update comment for _cont_fastpath
>  - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
>  - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
>  - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2422590696

From jwaters at openjdk.org  Fri Nov  8 05:34:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Nov 2024 05:34:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
Message-ID: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>

On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
> 
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
> 
> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

https://godbolt.org/z/xve7cbG1e

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463794511

From dholmes at openjdk.org  Fri Nov  8 05:34:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:34:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
Message-ID: <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>

On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> In the page you mentioned:

@alexmenkov  that is for C functions, not C++.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463796536

From dholmes at openjdk.org  Fri Nov  8 05:46:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:46:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
 <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>
Message-ID: <v52apX6P8vmous8o3RCQbeeoklOyCD8jjp1vwhw9zwY=.c7267189-58dd-484c-afed-9227686e44f3@github.com>

On Fri, 8 Nov 2024 05:26:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
>>> 
>>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>>> 
>>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.
>> 
>> In the page you mentioned:
>> 
>>  Format of a C decorated name
>> The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**.
>
>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
>> 
>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>> 
>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.
> 
> Not __stdcall: https://godbolt.org/z/nvjTP5WPc
> __stdcall: https://godbolt.org/z/1KejW44vY

Thanks @TheShermanTanker . I see the arguments do affect the encoding but the `__stdcall` makes no difference.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463816359

From dholmes at openjdk.org  Fri Nov  8 05:51:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:51:28 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <1D5bn5rgr4DaceNVvTisKsP3eAm-2R4D9DcZJ6gp1bk=.6add3137-d50a-488d-89e8-dd503d524e5c@github.com>

On Wed, 6 Nov 2024 15:21:10 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:
> 
>   Remove FIXME

Clearing my "changes requested" status

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2422752388

From ihse at openjdk.org  Fri Nov  8 09:35:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 09:35:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <uDshibe97YJEl86SlFE0UfYWTPOLQbc3qOylYvoM6DI=.32f63129-fc1e-4ffa-8719-231182471044@github.com>

On Thu, 7 Nov 2024 12:16:23 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:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here..

As I said, I think they are just as safe as any other changes -- the only difference is that it is perhaps not as well-known in the community that they only affect x86.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464232813

From amenkov at openjdk.org  Fri Nov  8 09:41:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Nov 2024 09:41:54 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
 <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>
Message-ID: <f8lYbWXchszFEUOQpQX1ZjcjJ5CIrCItloYsd_wpdoE=.e72ca656-58e2-4719-9409-44a2c343d607@github.com>

On Fri, 8 Nov 2024 05:29:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > In the page you mentioned:
> 
> @alexmenkov that is for C functions, not C++.

And also for `extern "C"` (AFAIU we export all C++ functions as extern "C")

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464243142

From shade at openjdk.org  Fri Nov  8 10:09:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Nov 2024 10:09:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <PG-hSNCegArTGhR1uGessvPoJk1Hx2O-tIya-B1fk6c=.6e5c5762-4c4f-46cf-b1b4-95f10627b183@github.com>

On Thu, 7 Nov 2024 12:16:23 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:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

> @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here..

Sure, fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464299781

From shade at openjdk.org  Fri Nov  8 10:17:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Nov 2024 10:17:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <l0-oBnOTlMFRQ9am7L0fCeHbR_HaqQHPpit55a-8oWY=.5b45329e-d763-4f5d-9dd1-f4ee74c5291c@github.com>

On Wed, 6 Nov 2024 15:21:10 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:
> 
>   Remove FIXME

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2423300933

From ihse at openjdk.org  Fri Nov  8 11:24:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:24:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v32]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <HJ_Q6vI8J-AQp08b97u6i6cMt-N_tJ8_z7st2ei3et0=.872787dc-e88d-48c0-bb51-86e3157ea61c@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 37 commits:

 - Merge branch 'master' into impl-JEP-479
 - Remove FIXME
 - fix: jvm_md.h was included, but not jvm.h...
 - Update copyright years
 - Merge branch 'master' into impl-JEP-479
 - JVM_EnqueueOperation do not need __stdcall name lookup anymore
 - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them
 - Fix build_agent_function_name to not handle "@"-stdcall style names
 - buildJniFunctionName is now identical on Windows and Unix, so unify it
 - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer
 - ... and 27 more: https://git.openjdk.org/jdk/compare/0c281acf...a9d56f2f

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

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31
  Stats: 1925 lines in 85 files changed: 86 ins; 1572 del; 267 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  Fri Nov  8 11:31:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:31:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@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:

  Inline buildJniFunctionName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/a9d56f2f..445515e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31-32

  Stats: 14 lines in 1 file changed: 4 ins; 9 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  Fri Nov  8 11:31:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:31:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
 <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
 <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>
Message-ID: <9-Gr4GhhtLOPX6w1PMSIcvx25_d9-MchNZtIId2mZLg=.79e4368a-412d-42c6-8db7-7288b50cb63e@github.com>

On Wed, 6 Nov 2024 21:24:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.
>
> The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here.  The second part,
> cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm
> okay with being in a followup.  I guess I can live with the first part being in that followup too.

Ok, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834182702

From pchilanomate at openjdk.org  Fri Nov  8 13:48:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <wQhIYGy1JULXOd4-arVYp3gABhb2Smg92LAQzCYj2kg=.ff7f91a4-9118-4cbc-a7d3-133271d09201@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 in JvmtiEnvBase::get_locked_objects_in_frame()
 - Add ObjectWaiter::at_monitorenter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/62b16c6a..3cdb8f86

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: 44 lines in 5 files changed: 36 ins; 1 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  Fri Nov  8 13:48:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>

On Wed, 30 Oct 2024 17:23:31 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:
>> 
>>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>>  - Add ObjectWaiter::at_monitorenter
>
> 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.

I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case.

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

I checked and release build is same size and fast/slow debug difference is only about 16kb. Since it doesn?t hurt I would rather not touch the fast paths, but I see `ConfigT` has been unused for some time now so I can do a follow up cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834427410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834425311

From mullan at openjdk.org  Fri Nov  8 13:49:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 8 Nov 2024 13:49:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@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 224 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=08
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 pchilanomate at openjdk.org  Fri Nov  8 13:48:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>
Message-ID: <4wpTgmx1V3RtcHOC0q-19yKgMwSg4og_30EdNvz6oA0=.d8be3ea5-7a30-4ec9-89cb-a013318189f2@github.com>

On Fri, 8 Nov 2024 13:43:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.
>
> I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case.

Thanks for pointing at this code because I also realized there is a nice cleanup that can be done here. First these methods should be moved to `java_lang_VirtualThread` class where they naturally belong (these are the equivalent of the JavaThread methods but for an unmounted vthread). Also the `objectWaiter` field can be added to the VirtualThread class rather than the stackChunk, which not?only is more appropriate too and gives us the get/set symmetry for these methods, but we can also save memory since one virtual thread can have many stackChunks around. I have a patch for that but I?ll do it after this PR to avoid new changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834429835

From bpb at openjdk.org  Fri Nov  8 16:24:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 8 Nov 2024 16:24:22 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
Message-ID: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>

Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

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

Commit messages:
 - 8343785: (fs) Remove syscalls that set file times with microsecond precision

Changes: https://git.openjdk.org/jdk/pull/21989/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21989&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343785
  Stats: 424 lines in 7 files changed: 37 ins; 310 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/21989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21989/head:pull/21989

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

From bpb at openjdk.org  Fri Nov  8 16:24:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 8 Nov 2024 16:24:22 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <Wf2v0bbR8WrhOFb2FhqO8gKO7pj0pw9xOuxGKDNlFCU=.45bcfc9c-9bd4-40c4-9d0d-95ffee9f3134@github.com>

On Fri, 8 Nov 2024 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

@TheRealMDoerr , @RealCLanger If this will eventually be integrated, it would be good if there were some testing on AIX before then. I don't think I've touched any AIX specific code, but one can't be too careful. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21989#issuecomment-2465198464

From duke at openjdk.org  Fri Nov  8 17:54:17 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 17:54:17 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: <yU4WXt45TjPWFSLDvknTnRDOG1gc0169uz9Cb4SmFIM=.9a8faece-9c7f-46e1-95ac-0b24e6cb0d10@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...).

@magicus @kimbarrett @shipilev Thanks for catching this. We want to get this working on Windows AArch64. I have filed https://bugs.openjdk.org/browse/JDK-8343857.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834839335

From aivanov at openjdk.org  Fri Nov  8 18:18:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Nov 2024 18:18:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
Message-ID: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>

On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> 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?
>
>> Is it intentional?
> 
> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?

It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).

Without the `@see` tag, one has to read the entire description to find the link.

It looks subtle. We can restore the `@see`-link later if deemed necessary.

Does anyone else have an opinion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826266398

From duke at openjdk.org  Fri Nov  8 18:29:37 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 18:29:37 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>

On Fri, 8 Nov 2024 11:31:40 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:
> 
>   Inline buildJniFunctionName

src/hotspot/os/posix/include/jvm_md.h line 41:

> 39: 
> 40: #define JNI_ONLOAD_SYMBOLS   {"JNI_OnLoad"}
> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"}

are these changes related to the Windows 32-bit x86 port?

src/hotspot/os/posix/os_posix.cpp line 699:

> 697: }
> 698: 
> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) {

are these changes related to the Windows 32-bit x86 port?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878288
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878195

From honkar at openjdk.org  Fri Nov  8 18:36:29 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 8 Nov 2024 18:36:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
Message-ID: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>

On Fri, 1 Nov 2024 20:26:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Is it intentional?
>> 
>> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?
>
> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
> 
> Without the `@see` tag, one has to read the entire description to find the link.
> 
> It looks subtle. We can restore the `@see`-link later if deemed necessary.
> 
> Does anyone else have an opinion?

I can add it back if it is more convenient and readable to have the `@see` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1834883137

From kbarrett at openjdk.org  Fri Nov  8 18:53:34 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Nov 2024 18:53:34 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <AK84V2NwC_9BcgrVVckQUIy-yELNx22fLrMgezMupr8=.6c642b1f-75d2-4ad6-b0f6-76b499d34f87@github.com>

On Fri, 8 Nov 2024 11:31:40 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:
> 
>   Inline buildJniFunctionName

Still looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424652542

From kbarrett at openjdk.org  Fri Nov  8 18:53:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Nov 2024 18:53:35 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
 <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>
Message-ID: <8YGMIrEQv6aPy_9IXzP9VqZ6tB0CTSwnH1XkfkDlXzM=.c1dd03d4-6d33-4dc8-a8b1-691a0616a6a5@github.com>

On Fri, 8 Nov 2024 18:26:25 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inline buildJniFunctionName
>
> src/hotspot/os/posix/include/jvm_md.h line 41:
> 
>> 39: 
>> 40: #define JNI_ONLOAD_SYMBOLS   {"JNI_OnLoad"}
>> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"}
> 
> are these changes related to the Windows 32-bit x86 port?

After removal of Windows 32-bit x86 port, all definitions of these macros are identical, so are merged into jvm.h.
There is additional followup work involving these: see https://bugs.openjdk.org/browse/JDK-8343703.

> src/hotspot/os/posix/os_posix.cpp line 699:
> 
>> 697: }
>> 698: 
>> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) {
> 
> are these changes related to the Windows 32-bit x86 port?

As part of removal of Windows 32-bit x86 port, these functions are no longer needed nor called, and all
definitions removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900456
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900337

From kvn at openjdk.org  Fri Nov  8 19:11:41 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Nov 2024 19:11:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <S-U2kCBhx9cweO0eJDjSJzkeUaEM5eQ_zhGBlgM7lnw=.9148cad5-1d30-43ca-a53d-f5912753cbb5@github.com>

On Fri, 8 Nov 2024 11:31:40 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:
> 
>   Inline buildJniFunctionName

Re-approve.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424696022

From duke at openjdk.org  Fri Nov  8 20:12:19 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 20:12:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <qZoG7f7Hk2WfNJoQgA7VgAbQj-uS-ta8A32bRTPXDa8=.b1e7d03a-cf33-42c4-bfe9-9db52e2ea465@github.com>

On Fri, 8 Nov 2024 11:31:40 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:
> 
>   Inline buildJniFunctionName

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

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424836232

From prr at openjdk.org  Fri Nov  8 21:05:41 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <dhLdeBXtuGvkkliM-T9_iulm4XDPiHmO7jzAkk64sfQ=.71503749-f671-4a6f-b734-0e75e944aca8@github.com>

On Fri, 8 Nov 2024 13:49: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 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2424915104

From prr at openjdk.org  Fri Nov  8 21:05:42 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
Message-ID: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>

On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > 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.
> 
> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
> 
> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
> 
> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

I think I was just saying there appeared to be dead code in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1835053637

From weijun at openjdk.org  Sat Nov  9 00:57:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 9 Nov 2024 00:57:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <R5hyTWGUzhiJE4SpPYJPTygHl6poBtz11qYOO6jeegQ=.32767fc6-3ca5-48bc-b491-d039d99083b8@github.com>

On Fri, 8 Nov 2024 13:49: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 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by weijun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2425106253

From duke at openjdk.org  Sat Nov  9 02:00:48 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:00:48 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if
 the default FileSystemProvider is not the system-default provider
Message-ID: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>

Use the built-in file system provider rather than the custom file system provider.
Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

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

Commit messages:
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

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

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

From duke at openjdk.org  Sat Nov  9 02:20:24 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:20:24 GMT
Subject: Withdrawn: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>
References: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>
Message-ID: <5Ro4ykZrKBJi-uUjZasJGxb_Y0WJo48V92QSM1C762s=.4b1a80ed-abaa-45dc-8b32-10a4ab81dcf7@github.com>

On Thu, 17 Oct 2024 03:37:38 GMT, jyxzwd <duke at openjdk.org> wrote:

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sat Nov  9 02:22:56 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:22:56 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if
 the default FileSystemProvider is not the system-default provider
Message-ID: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>

Use the built-in file system provider rather than the custom file system provider.
Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

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

Commit messages:
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

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

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

From alanb at openjdk.org  Sat Nov  9 08:56:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Nov 2024 08:56:18 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <hfDF29DMzotpGC8PPvvwNa-CrgQ1-reE_585Pm0zSHQ=.696b89af-f324-46a3-83fd-90f80b341175@github.com>

On Fri, 8 Nov 2024 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 59:

> 57:             if (lastModifiedTime == null || lastAccessTime == null) {
> 58:                 try {
> 59:                     UnixFileAttributes attrs = UnixFileAttributes.get(path, followLinks);

We should use openForAttributeAccess if possible. If lastModifiedTime or lastAccessTime is not provided then it ensures that this method will only access one file to avoid racing with concurrent changes on the file system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1835319664

From stuefe at openjdk.org  Sat Nov  9 07:24:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 9 Nov 2024 07:24:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <deG-5pSaioxX_iu3HGqZFikAnKlhDF8Mx962lPoKHSM=.1a200b5b-d345-41f9-adfc-9902849b0a63@github.com>

On Fri, 8 Nov 2024 11:31:40 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:
> 
>   Inline buildJniFunctionName

Still looks good to me.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2425254474

From alanb at openjdk.org  Sat Nov  9 09:00:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Nov 2024 09:00:52 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>

On Sat, 9 Nov 2024 02:18:22 GMT, jyxzwd <duke at openjdk.org> wrote:

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:

> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
> 50:     private static final Path BOOT_MODULES_JIMAGE =
> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");

This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835320287

From duke at openjdk.org  Sat Nov  9 13:09:20 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 13:09:20 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
Message-ID: <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>

On Sat, 9 Nov 2024 08:57:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Use the built-in file system provider rather than the custom file system provider.
>> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:
> 
>> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
>> 50:     private static final Path BOOT_MODULES_JIMAGE =
>> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");
> 
> This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.

I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
Thank you very much for your guidance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835357748

From alanb at openjdk.org  Sat Nov  9 18:15:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Nov 2024 18:15:12 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
Message-ID: <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>

On Sat, 9 Nov 2024 13:06:30 GMT, jyxzwd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:
>> 
>>> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
>>> 50:     private static final Path BOOT_MODULES_JIMAGE =
>>> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");
>> 
>> This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.
>
> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
> Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
> Thank you very much for your guidance.

The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.


String targetJDK = .
var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));


Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't reference JDK internal classes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835482157

From duke at openjdk.org  Sun Nov 10 04:54:40 2024
From: duke at openjdk.org (jyxzwd)
Date: Sun, 10 Nov 2024 04:54:40 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
Message-ID: <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>

On Sat, 9 Nov 2024 18:12:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
>> Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
>> Thank you very much for your guidance.
>
> The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.
> 
> 
> String targetJDK = .
> var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
> byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));
> 
> 
> Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are not defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't access JDK internal classes.

I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835576027

From duke at openjdk.org  Sun Nov 10 14:51:14 2024
From: duke at openjdk.org (jyxzwd)
Date: Sun, 10 Nov 2024 14:51:14 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
Message-ID: <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>

On Sun, 10 Nov 2024 04:50:36 GMT, jyxzwd <duke at openjdk.org> wrote:

>> The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.
>> 
>> 
>> String targetJDK = .
>> var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
>> byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));
>> 
>> 
>> Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are not defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't access JDK internal classes.
>
> I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.

If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.

In ImageReaderFactory:

private static final Path BOOT_MODULES_JIMAGE = null;

    static {
        // check installed providers
        for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
            if ("file".equalsIgnoreCase(provider.getScheme())) {
                try {
                    BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
                    if (BOOT_MODULES_JIMAGE != null) break;
                } catch (UnsupportedOperationException uoe) {
                }
            }
        }
    }

What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835713466

From alanb at openjdk.org  Sun Nov 10 17:07:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Nov 2024 17:07:36 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
 <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
Message-ID: <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>

On Sun, 10 Nov 2024 14:48:26 GMT, jyxzwd <duke at openjdk.org> wrote:

>> I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.
>
> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.
> 
> In ImageReaderFactory:
> 
> private static final Path BOOT_MODULES_JIMAGE = null;
> 
>     static {
>         // check installed providers
>         for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
>             if ("file".equalsIgnoreCase(provider.getScheme())) {
>                 try {
>                     BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
>                     if (BOOT_MODULES_JIMAGE != null) break;
>                 } catch (UnsupportedOperationException uoe) {
>                 }
>             }
>         }
>     }
> 
> What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!

I assume this will lead to recursive initialisation, e.g. `FileSystems.getFileSystem(URI.create("jrt:/"))` will use FileSystemProvider.installedProviders to iterate over the installed providers.

I don't have time to look into this more but I think it will have to reflectively get the FileSystem so that the code isn't compiled with references to the built-in provider, as in something like this (not tested):


    private static final Path BOOT_MODULES_JIMAGE;
    static {
        FileSystem fs;
        if (ImageReaderFactory.class.getClassLoader() == null) {
            // fs = DefaultFileSystemProvider.theFileSystem()
            try {
                fs = (FileSystem) Class.forName("sun.nio.fs.DefaultFileSystemProvider")
                        .getMethod("theFileSystem")
                        .invoke(null);
            } catch (Exception e) {
                throw new ExceptionInInitializerError(e);
            }
        } else {
            fs = FileSystems.getDefault();
        }
        BOOT_MODULES_JIMAGE = fs.getPath(JAVA_HOME, "lib", "modules");
    }

Also just to say that we need to create a good test for this issue. I expect it will be rarely to interpose on the default file system and use jrtfs at the same time, but that is what this bug report is about so we'll need to create a good test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835741459

From aivanov at openjdk.org  Mon Nov 11 17:43:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Nov 2024 17:43:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@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>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
 <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>
Message-ID: <VilcXY4GAxFg7sMG9MUvtI6XuOGtJLr1uokZFIV1ipc=.1ad3e90d-fd00-49f4-9468-24651fa74cd5@github.com>

On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

>>> 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.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
>
>> > 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.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
> 
> I think I was just saying there appeared to be dead code in the test.

> > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>
> I think I was just saying there appeared to be dead code in the test.

Hmm? `createPrivateValue` had been called from the `main` method, so it had been used in the test until it was removed in https://github.com/openjdk/jdk/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

Since `MultiUIDefaults` is still used in `UIManager` and we're keeping the test, I'm for keeping a test for `createPrivateValue` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1837009964

From pchilanomate at openjdk.org  Tue Nov 12 02:59:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 02:59:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@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 with a new target base due to a merge or a rebase. The pull request now contains 90 commits:

 - Merge branch 'master' into JDK-8338383
 - Test StopThreadTest.java: fix operator in condition + improve names
 - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
 - Merge branch 'master' into JDK-8338383
 - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
 - Add ObjectWaiter::at_monitorenter
 - Use get_method_name + copyright revert in jvmtiThreadState.cpp
 - Merge branch 'master' into JDK-8338383
 - Add @requires vm.continuations to CancelTimerWithContention.java
 - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
 - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

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

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04
  Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 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 Nov 12 03:04:35 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 03:04:35 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <b5MrSDTiXfMTA2UztpWjFYP1Vfu5SAe6OOhnv2tgVI4=.ebe93ebe-1e63-44d4-8b90-922648b83bbf@github.com>

On Tue, 12 Nov 2024 02:59:59 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 with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

I merged with master, including the changes for [JEP 450](https://github.com/openjdk/jdk/pull/20677), and run it through tiers1-8 in mach5 with no related failures. I would like to integrate tomorrow if I could get some re-approvals. Also, I filed JDK-8343957 to possibly improve the naming of `_lock_id/owner_from` as discussed in some of the comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2469493942

From dholmes at openjdk.org  Tue Nov 12 07:09:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Nov 2024 07:09:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <3vfCjVBL-b8oC8v_8fW5QdXjAT1ssSjfPgFoNL1fNu0=.d7efc5eb-3e84-42b5-b8ce-9c9cc11900bf@github.com>

On Tue, 12 Nov 2024 02:59:59 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 with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Still good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2428723863

From swen at openjdk.org  Tue Nov 12 07:53:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 07:53:44 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
Message-ID: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>

In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

Commit messages:
 - fix unsafe address overflow

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

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

From swen at openjdk.org  Tue Nov 12 07:53:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 07:53:45 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <DAezQSy8R0shDTX5eo0F9PE-eelF6XXotAGMMPuosmk=.221dbe26-d2b3-431d-851a-4e688ee737d4@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

There are two other possible address overflow issues that are difficult to fix:

java.util.zip.CRC32C::updateBytes
jdk.internal.util.ArraysSupport::mismatch

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469804720

From pminborg at openjdk.org  Tue Nov 12 08:18:31 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 08:18:31 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:

> 33:     public static char getChar(byte[] val, int index) {
> 34:         return unsafe.getChar(val,
> 35:                 (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L);

This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837653228

From swen at openjdk.org  Tue Nov 12 08:26:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:26:44 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  revert, from @minborg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/8087831c..b9294369

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

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

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

From swen at openjdk.org  Tue Nov 12 08:26:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:26:46 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>
Message-ID: <SH0n4NOq6honMDzHgKibB892wJhYWSL7J4tzrs9GfBY=.5a954b9b-8c8f-4d83-83e8-b3b594fb493c@github.com>

On Tue, 12 Nov 2024 08:15:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert, from @minborg
>
> src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:
> 
>> 33:     public static char getChar(byte[] val, int index) {
>> 34:         return unsafe.getChar(val,
>> 35:                 (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L);
> 
> This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is?

You are right, there is no need to add an explicit type conversion here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837663142

From pminborg at openjdk.org  Tue Nov 12 08:47:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 08:47:48 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>
Message-ID: <_prE4LHsGuZK3LlsVUCgGOCjPIlLQ8XRfgZG37p9LGo=.32f61ce8-642f-46d9-b597-d4bcc1118ed9@github.com>

On Tue, 12 Nov 2024 08:26:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert, from @minborg

It would be good to add some tests to ensure `long` precision is used.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1006:

> 1004:     }
> 1005: 
> 1006:     private void writeBooleanArray(TypeArray array, int length) throws IOException {

Note that the copyright year needs updating.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 4104:

> 4102:     @ForceInline
> 4103:     static long byteArrayAddress(byte[] a, int index) {
> 4104:         return (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

These classes are generated via the `X-Vector.java.template` in the `java.incubator.vector` package.  So, you only need to change one file here.

![image](https://github.com/user-attachments/assets/2dbda48c-ae17-4809-a46f-62065ee9eab3)

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469916847
PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837687593
PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837685399

From swen at openjdk.org  Tue Nov 12 08:59:30 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:59:30 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  from @minborg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/b9294369..c719c7d1

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

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

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

From alanb at openjdk.org  Tue Nov 12 09:06:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 09:06:30 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
Message-ID: <EqegOGMDco6H1rHwIzD5VMscYRKNfmI97cgGk5-kBHs=.56f471bf-0d27-4023-bfc4-a0b366664449@github.com>

On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @minborg

src/java.base/share/classes/java/lang/StringLatin1.java line 836:

> 834:         UNSAFE.putByte(val, address    , (byte)(c1));
> 835:         UNSAFE.putByte(val, address + 1, (byte)(c2));
> 836:         UNSAFE.putByte(val, address + 2, (byte)(c3));

While you are here, I wonder if this should be renamed to offset to make it clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837720784

From pminborg at openjdk.org  Tue Nov 12 09:12:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 09:12:05 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
Message-ID: <RQC57LlR6hYt0xtByw8ExA7DcJLMYFAKSfRT4TYXCoc=.fcbbaa7b-793a-4058-a192-6292527d01c2@github.com>

On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @minborg

The generation of Java files works a bit differently from other places in the JDK (e.g. NIO). Now that the template has been changed, you also need to manually run the script `gen-src.sh` in order to regenerate the classes. So, they will then show up like they did in an earlier commit but share a single source of truth.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469971317

From swen at openjdk.org  Tue Nov 12 09:55:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 09:55:17 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v4]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <1bBT7IyN6vjZdTpD2gEs-yLSrR-QnRDabKs9TeQmcSs=.c9b61faf-0606-439e-b6de-1186c21d2b4f@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - re gen-src
 - rename address to offset, from @AlanBateman

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/c719c7d1..4e007699

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

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

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

From aboldtch at openjdk.org  Tue Nov 12 10:16:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 12 Nov 2024 10:16:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <bpk-IWu7LnUBHxulw1MpQd9rNMI5fdo6AN7TTy4HdQo=.c1821677-7733-42d5-9c08-42979ed5ccaa@github.com>

On Tue, 12 Nov 2024 02:59:59 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 with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2429155294

From swen at openjdk.org  Tue Nov 12 11:24:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 11:24:24 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  rename address to offset, from @AlanBateman

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/4e007699..f8f58546

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

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

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

From pminborg at openjdk.org  Tue Nov 12 11:37:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 11:37:17 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <RWhDwE0NcEu8f3DzeNV422vYWAea3tdbO6RfOO4Ymlk=.be849fcc-e951-4c57-9d07-c5388bc57d12@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

LGTM. If there are no additional tests, please label the JBS issue appropriately (i.e `noreg-*`)

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429343536

From alanb at openjdk.org  Tue Nov 12 12:13:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 12:13:23 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429423006

From pminborg at openjdk.org  Tue Nov 12 12:20:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 12:20:10 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

> I want to add such a test case, but I am worried that it will consume too many resources during the build process.
> 
> ```java
> /**
>  * @test
>  * @bug 8343984
>  * @summary Test that the append capacity is close to Integer.MaxValue
>  * @run main/othervm -Xms6g -Xmx6g HugeAppend
>  */
> 
> public final class HugeAppend {
>     public static void main(String[] args) {
>         StringBuilder buf = new StringBuilder();
>         int loop4 = Integer.MAX_VALUE / 4;
>         for (int i = 0; i < loop4; i++) {
>             buf.append(true);
>         }
> 
>         buf.setLength(0);
>         int loop5 = Integer.MAX_VALUE / 5;
>         for (int i = 0; i < loop5; i++) {
>             buf.append(false);
>         }
>     }
> }
> ```

Yeah. I think it is reasonable to leave out such tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470383131

From swen at openjdk.org  Tue Nov 12 12:20:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 12:20:10 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <toDl2zq66ni0iW4AVMTMCNLjRclBgaqs93EvF8BTBKs=.f438c6e5-1c3a-4793-a061-08813ae69c8b@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

I want to add such a test case, but I am worried that it will consume too many resources during the build process.


/**
 * @test
 * @bug 8343984
 * @summary Test that the append capacity is close to Integer.MaxValue
 * @run main/othervm -Xms6g -Xmx6g HugeAppend
 */

public final class HugeAppend {
    public static void main(String[] args) {
        StringBuilder buf = new StringBuilder();
        int loop4 = Integer.MAX_VALUE / 4;
        for (int i = 0; i < loop4; i++) {
            buf.append(true);
        }

        buf.setLength(0);
        int loop5 = Integer.MAX_VALUE / 5;
        for (int i = 0; i < loop5; i++) {
            buf.append(false);
        }
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470377122

From mullan at openjdk.org  Tue Nov 12 13:01:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 13:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@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 229 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=09
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 swen at openjdk.org  Tue Nov 12 13:48:35 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 13:48:35 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <IxQspJjd_7i-U-w_ros1GPC9YVmXJf-hoIXhIM-8ZwQ=.26bc602d-e995-4989-9d92-a7f096bbac25@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

macos-aarch64 build error, I have been encountering this problem for the past two days. How do I solve it?

Run # On macOS we need to install some dependencies for testing
  # On macOS we need to install some dependencies for testing
  brew install make
  sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer
  # This will make GNU make available as 'make' and not only as 'gmake'
  echo '/usr/local/opt/make/libexec/gnubin' >> $GITHUB_PATH
  shell: /bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    MSYS[2](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:2)_PATH_TYPE: minimal
    CHERE_INVOKING: 1
==> Downloading https://ghcr.io/v2/homebrew/core/make/manifests/4.4.1-1
==> Fetching make
==> Downloading https://ghcr.io/v2/homebrew/core/make/blobs/sha256:94[3](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:3)77dc5a364da305c75fd7aa923a[4](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:4)2897993de9edd1eb074428e13c3f2aaf93
==> Pouring make--4.4.1.arm64_sonoma.bottle.1.tar.gz
==> Caveats
GNU "make" has been installed as "gmake".
If you need to use it as "make", you can add a "gnubin" directory
to your PATH from your bashrc like:

    PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"
==> Summary
?  /opt/homebrew/Cellar/make/4.4.1: 1[7](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:7) files, 1.3MB
xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app/Contents/Developer'
Error: Process completed with exit code 1.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470568595

From kevinw at openjdk.org  Tue Nov 12 14:18:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:18:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <k5Fku2GFLG_4KD-l9l4gX4gnu8qrfvtTcWWNxvZQTus=.b710907b-e5a3-4516-bdbf-047a74a5eacd@github.com>

On Tue, 12 Nov 2024 13:01:33 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 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429727015

From swen at openjdk.org  Tue Nov 12 14:22:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 14:22:11 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>
Message-ID: <GeWLCVVrOttuWEvm0HtRxLT1GKyE7-QK4QOe4jfDeg8=.2494cc13-0aeb-47bc-a473-3f85c0540661@github.com>

On Tue, 12 Nov 2024 12:18:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I want to add such a test case, but I am worried that it will consume too many resources during the build process.
> 
> ```java
> /**
>  * @test
>  * @bug 8343984
>  * @summary Test that the append capacity is close to Integer.MaxValue
>  * @run main/othervm -Xms6g -Xmx6g HugeAppend
>  */
> 
> public final class HugeAppend {
>     public static void main(String[] args) {
>         StringBuilder buf = new StringBuilder();
>         int loop4 = Integer.MAX_VALUE / 4;
>         for (int i = 0; i < loop4; i++) {
>             buf.append(true);
>         }
> 
>         buf.setLength(0);
>         int loop5 = Integer.MAX_VALUE / 5;
>         for (int i = 0; i < loop5; i++) {
>             buf.append(false);
>         }
>     }
> }
> ```

In the master branch, this test will succeed in jtreg

* jtreg

make test TEST="jtreg:test/jdk/java/util/BitSet/HugeToString.java"


* result

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/util/BitSet/HugeToString.java     1     1     0     0   
==============================
TEST SUCCESS


But running it directly will cause JVM Crash

 ~/git/jdk_x/build/macosx-aarch64-server-release/images/jdk/bin/java -Xms6g -Xmx6g HugeAppend

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470661592

From rriggs at openjdk.org  Tue Nov 12 14:25:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:25:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <T-riVwSNCriZvC4nhb9XDviF7n0SacK4KEJz3f8t2b0=.93469aae-25e3-4e33-9232-7b3337219821@github.com>

On Tue, 12 Nov 2024 13:01:33 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 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Good to go!

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429741829

From mullan at openjdk.org  Tue Nov 12 14:44:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 14:44:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@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 230 commits:

 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=10
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 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 kevinw at openjdk.org  Tue Nov 12 14:48:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:48:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <qw2I4_NVSBXQhXFeevleFvLgLEvPhUspdKzt2D4vSxo=.4251f226-49c6-450c-95f1-5bbd252554a2@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429813961

From rriggs at openjdk.org  Tue Nov 12 14:55:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:55:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <yAGTVrMWpR2BOpXL3-RivxcpB7UUrza89gERwz1BarA=.70d7df81-ea72-4379-848b-6438759d92a3@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429830332

From mullan at openjdk.org  Tue Nov 12 15:05:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:09 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
Message-ID: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>

On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
>> 
>> Without the `@see` tag, one has to read the entire description to find the link.
>> 
>> It looks subtle. We can restore the `@see`-link later if deemed necessary.
>> 
>> Does anyone else have an opinion?
>
> I can add it back if it is more convenient and readable to have the `@see` tag.

This can be taken care of later after integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838260852

From mullan at openjdk.org  Tue Nov 12 15:05:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:14 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: <-KIDgN-bR6eT5GTOj2hiyz0oLJXR7Ewx1taEzXeaRsw=.3d2f141a-8183-4f70-af74-c06b47f29478@github.com>

On Thu, 24 Oct 2024 17:03: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
>
> 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?

This can be handled later in a more general cleanup task.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838259103

From mullan at openjdk.org  Tue Nov 12 15:05:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
Message-ID: <yml_wtm2Rsmw63hY1b6cxp1EvRCPyJFD7cVRxerdgb4=.6ef7f62e-7ce0-4661-9951-3445f851d94b@github.com>

On Fri, 1 Nov 2024 19:40:03 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 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
>
> test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:
> 
>> 1: /*
> 
> I wonder if we should add an Oracle copyright to the update test file.

I don't think it is necessary for that small of a change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838256317

From pchilanomate at openjdk.org  Tue Nov 12 15:16:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 15:16:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <A_fEv9pCgcr1SaNUUBjzJWqpenFyplpeTeEcW2YurcE=.17d74ae6-cea8-4107-8597-1fcacac27562@github.com>

On Tue, 12 Nov 2024 02:59:59 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 with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Many thanks to all reviewers and contributors of this JEP!

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2470802813

From rriggs at openjdk.org  Tue Nov 12 15:17:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y18nI8ZKAB47qMMhqmhSOhr-kknoaDFEyLm2UHrcK7E=.07f02e84-b49e-485d-82c0-5f8ef3a78718@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429896801

From aivanov at openjdk.org  Tue Nov 12 15:17:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@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>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
 <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>
Message-ID: <ZJ2gt2LT5Xcrgjc9gpjOIn87PHt9uFilNQKSplRKd3g=.7da1b1dc-c572-4a7a-a07c-460a38a1f637@github.com>

On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I can add it back if it is more convenient and readable to have the `@see` tag.
>
> This can be taken care of later after integration.

Agreed!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282210

From pchilanomate at openjdk.org  Tue Nov 12 15:27:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 15:27:02 GMT
Subject: Integrated: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <EXnxvKvm9l0yuV-jt5tIPzV3JL8hoSSstko26DrlKN0=.fcd823c0-7588-4b2a-8308-3125094a41c6@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...

This pull request has now been integrated.

Changeset: 78b80150
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78b80150e009745b8f28d36c3836f18ad0ca921f
Stats:     9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod

8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: aboldtch, dholmes, coleenp, fbredberg, dlong, sspitsyn

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

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

From swen at openjdk.org  Tue Nov 12 15:54:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 15:54:00 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v6]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  more fix unsafe address overflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/f8f58546..97615464

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

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

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

From swen at openjdk.org  Tue Nov 12 15:54:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 15:54:00 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
Message-ID: <NgZerEQu2KGipyyDbIip-FR2tonnWpVra8iR81-Pkso=.c93d1921-3c84-428f-a98e-911baa95f49b@github.com>

On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman @minborg 
Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470896128

From lancea at openjdk.org  Tue Nov 12 16:00:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 12 Nov 2024 16:00:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <T4XvpsK7Crm19k2etafDqv0D5yoZLmLgGNw9Xk2ogdg=.5af67060-a5a1-49a5-8014-4b808b810e4f@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Thank you for all of your hard work on this JEP Sean.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430018834

From coffeys at openjdk.org  Tue Nov 12 16:03:27 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 12 Nov 2024 16:03:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <S2BNzehI36J_Jflq6pI9AuDrfYsA8dTAeE3jCac-Bh8=.7baf781b-3caa-44cd-acb6-9f75055c353b@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430024985

From aivanov at openjdk.org  Tue Nov 12 16:11:19 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 16:11:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y-mlQzl5xkWAglmNtQjN9AQH27dL2Lj1uviN_EQ5wTk=.29bd4e0c-560a-4b39-a743-9aefd78009a4@github.com>

On Tue, 12 Nov 2024 14:44: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 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430049235

From alanb at openjdk.org  Tue Nov 12 16:25:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:25:39 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v6]
In-Reply-To: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>
Message-ID: <uO1_Z-TC4tXY1a-nkYdwlHSXCdoVaz5t14uPomm6mK4=.7c6ab72b-3ed3-4e5d-8789-34a05eccdb12@github.com>

On Tue, 12 Nov 2024 15:54:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fix unsafe address overflow

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2430082452

From alanb at openjdk.org  Tue Nov 12 16:25:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:25:40 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
Message-ID: <ZMXQV7nYoJC83kfU7dqLwH3w1r6tO-vy7RncDn3dvHw=.104a7370-97cf-4472-aba5-8d0e572e4ed3@github.com>

On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).

> @AlanBateman @minborg Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

Looks good, can you bump the copyright header on UnixUserDefinedFileAttributeView too?

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470974166

From swen at openjdk.org  Tue Nov 12 16:30:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 16:30:12 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  fix copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/97615464..980cb229

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

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

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

From swen at openjdk.org  Tue Nov 12 16:40:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 16:40:19 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

@liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471016555

From alanb at openjdk.org  Tue Nov 12 16:46:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:46:31 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
 <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>
Message-ID: <Bm5lcsyGVXB5eofGWWWkiW1D0Rq63U8odOUyfV-t1X4=.2e113503-0d00-4925-a8f2-e689e492a64f@github.com>

On Tue, 12 Nov 2024 16:37:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> @liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

I discussed this briefly with him today, he's looking into the implications of doing that.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471038775

From liach at openjdk.org  Tue Nov 12 16:52:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 16:52:23 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <00Pb2OkiKtnrABDOzIvqOFhuNoXn6UyPiy-P1Nu_Nhw=.8bd821bb-2cb6-44da-b39c-72047bad43b1@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

I think this patch can go ahead: the change to internal unsafe will affect many other components and all use sites will get bytecode updates.  The more comprehensive change will need more throughout investigation and testing, while the fixes here are straightforward and easy to verify.

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

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471054020

From mullan at openjdk.org  Tue Nov 12 17:20:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 17:20:26 GMT
Subject: Integrated: 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: <Q0nD82TeeHNB3GUN883I9z2gNYRVerdm8O57BFweQMM=.43d95216-fd1d-4252-abb0-8eaec40efb61@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 pull request has now been integrated.

Changeset: db850905
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db85090553ab14a84c3ed0a2604dd56c5b6e6982
Stats:     68914 lines in 1889 files changed: 2475 ins; 62597 del; 3842 mod

8338411: Implement JEP 486: Permanently Disable the Security Manager

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Co-authored-by: Aleksei Efimov <aefimov at openjdk.org>
Co-authored-by: Brian Burkhalter <bpb at openjdk.org>
Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Co-authored-by: Harshitha Onkar <honkar at openjdk.org>
Co-authored-by: Joe Wang <joehw at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Justin Lu <jlu at openjdk.org>
Co-authored-by: Kevin Walls <kevinw at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Naoto Sato <naoto at openjdk.org>
Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Co-authored-by: Brent Christian <bchristi at openjdk.org>
Co-authored-by: Stuart Marks <smarks at openjdk.org>
Co-authored-by: Ian Graves <igraves at openjdk.org>
Co-authored-by: Phil Race <prr at openjdk.org>
Co-authored-by: Erik Gahlin <egahlin at openjdk.org>
Co-authored-by: Jaikiran Pai <jpai at openjdk.org>
Reviewed-by: kevinw, aivanov, rriggs, lancea, coffeys, dfuchs, ihse, erikj, cjplummer, coleenp, naoto, mchung, prr, weijun, joehw, azvegint, psadhukhan, bchristi, sundar, attila

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

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

From aturbanov at openjdk.org  Tue Nov 12 19:24:40 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Nov 2024 19:24:40 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <013IDnPHZGWmc4UzSBT7XqM75Z1A75thB8ddw7WyULs=.66fd0968-f736-48c3-8aaf-d50d1d115b1f@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

src/java.base/share/classes/java/lang/StringLatin1.java line 833:

> 831:         assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check";
> 832:         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
> 833:         long offset  = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

Suggestion:

        long offset = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1838642848

From aturbanov at openjdk.org  Tue Nov 12 19:28:22 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Nov 2024 19:28:22 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <cH3DwJClXord2RXkukaC9_6gcr4qDtebS8qClS2il6Y=.a471feba-dd81-4237-9f93-2128fc5fe5b8@github.com>

On Fri, 8 Nov 2024 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 106:

> 104:             try {
> 105:                 setattrlist(path, commonattr, 0L, 0L, createValue,
> 106:                     followLinks ?  0 : UnixConstants.FSOPT_NOFOLLOW);

Suggestion:

                    followLinks ? 0 : UnixConstants.FSOPT_NOFOLLOW);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1838647936

From mdoerr at openjdk.org  Tue Nov 12 20:22:26 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 12 Nov 2024 20:22:26 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <WVk1u1pxe8_OBEWj5y0-H-bQ07jmVyuCCVdfrJ5WQRs=.b947079a-a313-46a3-ab33-f8f3f79fdb05@github.com>

On Fri, 8 Nov 2024 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

The included test has passed on linuxppc64le, but is disabled for AIX. At least the build has worked on AIX. We should try other tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/21989#issuecomment-2471501891

From bpb at openjdk.org  Tue Nov 12 20:46:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 12 Nov 2024 20:46:52 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <WVk1u1pxe8_OBEWj5y0-H-bQ07jmVyuCCVdfrJ5WQRs=.b947079a-a313-46a3-ab33-f8f3f79fdb05@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <WVk1u1pxe8_OBEWj5y0-H-bQ07jmVyuCCVdfrJ5WQRs=.b947079a-a313-46a3-ab33-f8f3f79fdb05@github.com>
Message-ID: <Gh1p_Cz8TmnzI52T6jX82_VqoEV7demY4XSfzR9zK9w=.1629428e-8252-4c53-b2a5-9fbecd61d252@github.com>

On Tue, 12 Nov 2024 20:19:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> The included test has passed on linuxppc64le, but is disabled for AIX.

I guess we should add `os.family = "aix"` to the `@requires`.

> At least the build has worked on AIX.

Good. Thanks for checking.

> We should try other tests.

Yes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21989#issuecomment-2471543952

From swen at openjdk.org  Tue Nov 12 23:34:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 23:34:48 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

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

  Update src/java.base/share/classes/java/lang/StringLatin1.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/980cb229..e66578ca

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

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

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

From bpb at openjdk.org  Wed Nov 13 00:47:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 00:47:49 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

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

  8343785: Use file descriptor in preference to path; add AIX to test @requires

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21989/files
  - new: https://git.openjdk.org/jdk/pull/21989/files/5442e7ce..ef3d0a45

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

  Stats: 163 lines in 3 files changed: 80 ins; 17 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/21989.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21989/head:pull/21989

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

From clanger at openjdk.org  Wed Nov 13 06:19:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Nov 2024 06:19:55 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
Message-ID: <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>

On Wed, 13 Nov 2024 00:47:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343785: Use file descriptor in preference to path; add AIX to test @requires

test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java line 29:

> 27:  * @requires (os.family == "aix") | (os.family == "linux") |
> 28:  *           (os.family == "mac") | (os.family == "windows")
> 29:  * @library ../.. /test/lib

I'll run another set of testing. Should the test work on AIX, I think we can remove the `@requires` section altogether.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1839519406

From alanb at openjdk.org  Wed Nov 13 07:40:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 07:40:55 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
Message-ID: <6bApISnYnGNmKlxN1xUIGgD6t1Ncf1EtAUvD8lYteE4=.39eb53a0-9643-4dcb-a133-bd80297389fd@github.com>

On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringLatin1.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432158366

From pminborg at openjdk.org  Wed Nov 13 07:48:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 07:48:32 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
Message-ID: <J336kGkSSw9twyKsuZ6mOIIpSEHehKAxpxyAk_18-8M=.4e67a2cf-cee7-4555-af3c-f034a329508d@github.com>

On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringLatin1.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Great with the additional fixes.

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432171697

From ihse at openjdk.org  Wed Nov 13 09:47:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Nov 2024 09:47:13 GMT
Subject: Integrated: 8339783: Implement 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: <DWWt17muH2zF1oJ5TI8hhjiujsGX7u33TGO446kd5_Y=.d51e25e6-2321-40e2-9ea1-c73108af6998@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.

This pull request has now been integrated.

Changeset: 79345bbb
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79345bbbae2564f9f523859d1227a1784293b20f
Stats:     1922 lines in 85 files changed: 82 ins; 1573 del; 267 mod

8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port

Reviewed-by: kbarrett, kvn, stuefe, shade, erikj

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

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

From alanb at openjdk.org  Wed Nov 13 10:22:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 10:22:03 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
Message-ID: <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>

On Wed, 13 Nov 2024 00:47:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343785: Use file descriptor in preference to path; add AIX to test @requires

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 80:

> 78:             // if path is a symlink, then the open should fail with ELOOP and
> 79:             // the path will be used instead of the file descriptor.
> 80:             boolean haveFd = false;

In passing, we don't need haveFd, instead we can use fd >= 0 as is done in other places.

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 83:

> 81:             int fd = -1;
> 82:             try {
> 83:                 fd = file.openForAttributeAccess(followLinks);

This throws if O_NOFOLLOW is not supported. Are there any platforms where this is possible?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1839879979
PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1839882104

From alanb at openjdk.org  Wed Nov 13 10:22:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 10:22:05 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>
Message-ID: <slfUlLv5d75Xl2zmpr9DaQHR0Ct-YKDvmPveM6-q-yA=.4c55e951-b5d4-4417-9d68-a0cf1444f92b@github.com>

On Wed, 13 Nov 2024 06:16:19 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343785: Use file descriptor in preference to path; add AIX to test @requires
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java line 29:
> 
>> 27:  * @requires (os.family == "aix") | (os.family == "linux") |
>> 28:  *           (os.family == "mac") | (os.family == "windows")
>> 29:  * @library ../.. /test/lib
> 
> I'll run another set of testing. Should the test work on AIX, I think we can remove the `@requires` section altogether.

Yes, I think `@requires` can be dropped now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1839885462

From alanb at openjdk.org  Wed Nov 13 10:56:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 10:56:47 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <ZUtXH5LRVvMxJxmVtIwGr1uGYVtRicgUKPdtlD7I1ts=.96d095d5-21f5-42f3-965e-5bcb7573bba9@github.com>

On Wed, 6 Nov 2024 00:15:44 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

@tprinzing Are you planning on all the tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2473184324

From mdoerr at openjdk.org  Wed Nov 13 11:59:56 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 13 Nov 2024 11:59:56 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>
Message-ID: <3BnnKP8KtvWEWXGNdey6n6yTaRmYQjjGSvEYWY020cU=.70678fff-8368-4aba-93c9-587db1434ee9@github.com>

On Wed, 13 Nov 2024 09:59:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343785: Use file descriptor in preference to path; add AIX to test @requires
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 83:
> 
>> 81:             int fd = -1;
>> 82:             try {
>> 83:                 fd = file.openForAttributeAccess(followLinks);
> 
> This throws if O_NOFOLLOW is not supported. Are there any platforms where this is possible?

I believe some old AIX versions. But they are no longer supported. We require 7.2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1840129031

From mdoerr at openjdk.org  Wed Nov 13 11:59:58 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 13 Nov 2024 11:59:58 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <slfUlLv5d75Xl2zmpr9DaQHR0Ct-YKDvmPveM6-q-yA=.4c55e951-b5d4-4417-9d68-a0cf1444f92b@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>
 <slfUlLv5d75Xl2zmpr9DaQHR0Ct-YKDvmPveM6-q-yA=.4c55e951-b5d4-4417-9d68-a0cf1444f92b@github.com>
Message-ID: <esKlBFFQbMdr0Q-Df3SnogHe3tbrqoFDxk2zIANCW64=.cc52090d-2547-4bcf-b055-52f24047b357@github.com>

On Wed, 13 Nov 2024 10:01:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java line 29:
>> 
>>> 27:  * @requires (os.family == "aix") | (os.family == "linux") |
>>> 28:  *           (os.family == "mac") | (os.family == "windows")
>>> 29:  * @library ../.. /test/lib
>> 
>> I'll run another set of testing. Should the test work on AIX, I think we can remove the `@requires` section altogether.
>
> Yes, I think `@requires` can be dropped now.

Yes, the test has passed on AIX.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1840127718

From alanb at openjdk.org  Wed Nov 13 14:31:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 14:31:32 GMT
Subject: RFR: 8344112: Remove code to support security manager execution mode
 from DatagramChannel implementation
Message-ID: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>

Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.

Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22072/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344112
  Stats: 206 lines in 2 files changed: 4 ins; 168 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/22072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22072/head:pull/22072

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

From dfuchs at openjdk.org  Wed Nov 13 15:14:39 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Nov 2024 15:14:39 GMT
Subject: RFR: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
Message-ID: <ldOgAs0wU-14C-NlI25k34cglU0E6n7O2eQAeH4IsPs=.20d3af3d-93a7-4588-a0cf-6041df513ccd@github.com>

On Wed, 13 Nov 2024 14:07:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.
> 
> Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 633:

> 631:                     try {
> 632:                         SocketAddress sender = sourceSocketAddress();
> 633:                         synchronized (p) {

I wonder if we should rip off the use of `synchronized (p)` in this method  and call

    synchronized (p) {
       blockingReceive(p, ...);
    }


In the adaptor instead, like it used to be before virtual threads came into the picture?

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 1492:

> 1490:                 Method m = AbstractSelectableChannel.class.getDeclaredMethod("forEach", Consumer.class);
> 1491:                 m.setAccessible(true);
> 1492:                 FOREACH = m;

Should we use this opportunity to use MethodHandle instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840536606
PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840528582

From alanb at openjdk.org  Wed Nov 13 15:14:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 15:14:39 GMT
Subject: RFR: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <ldOgAs0wU-14C-NlI25k34cglU0E6n7O2eQAeH4IsPs=.20d3af3d-93a7-4588-a0cf-6041df513ccd@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
 <ldOgAs0wU-14C-NlI25k34cglU0E6n7O2eQAeH4IsPs=.20d3af3d-93a7-4588-a0cf-6041df513ccd@github.com>
Message-ID: <_NPO_M0DGyNrGNQZcI51YrkMoo4sy0NUGDc0AclcAIg=.9ba3f610-2bf6-4ba2-bab4-48d80108c744@github.com>

On Wed, 13 Nov 2024 15:09:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.
>> 
>> Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.
>
> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 633:
> 
>> 631:                     try {
>> 632:                         SocketAddress sender = sourceSocketAddress();
>> 633:                         synchronized (p) {
> 
> I wonder if we should rip off the use of `synchronized (p)` in this method  and call
> 
>     synchronized (p) {
>        blockingReceive(p, ...);
>     }
> 
> 
> In the adaptor instead, like it used to be before virtual threads came into the picture?

Not this PR but there is a follow-up coming that will drop the dependency on DatagramPacket from DatagramChannelImpl so that it does back to the adaptor.

> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 1492:
> 
>> 1490:                 Method m = AbstractSelectableChannel.class.getDeclaredMethod("forEach", Consumer.class);
>> 1491:                 m.setAccessible(true);
>> 1492:                 FOREACH = m;
> 
> Should we use this opportunity to use MethodHandle instead?

It could be changed but not related to this PR so I'd prefer not do it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840546535
PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840543714

From dfuchs at openjdk.org  Wed Nov 13 15:20:49 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Nov 2024 15:20:49 GMT
Subject: RFR: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
Message-ID: <nr4od8_aBk0jqr_jdK71puf1qIUDvWzbGlf93gNf6qs=.45080b63-5380-41d4-8617-f251495f0758@github.com>

On Wed, 13 Nov 2024 14:07:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.
> 
> Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22072#pullrequestreview-2433564804

From dfuchs at openjdk.org  Wed Nov 13 15:20:51 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 13 Nov 2024 15:20:51 GMT
Subject: RFR: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <_NPO_M0DGyNrGNQZcI51YrkMoo4sy0NUGDc0AclcAIg=.9ba3f610-2bf6-4ba2-bab4-48d80108c744@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
 <ldOgAs0wU-14C-NlI25k34cglU0E6n7O2eQAeH4IsPs=.20d3af3d-93a7-4588-a0cf-6041df513ccd@github.com>
 <_NPO_M0DGyNrGNQZcI51YrkMoo4sy0NUGDc0AclcAIg=.9ba3f610-2bf6-4ba2-bab4-48d80108c744@github.com>
Message-ID: <EnubevSFfLNv2T17lVNO8JAiK8bzqVkvl8TPFxkWRYA=.32a5f28c-bd8c-4249-bd66-179d4aefcd02@github.com>

On Wed, 13 Nov 2024 15:12:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 633:
>> 
>>> 631:                     try {
>>> 632:                         SocketAddress sender = sourceSocketAddress();
>>> 633:                         synchronized (p) {
>> 
>> I wonder if we should rip off the use of `synchronized (p)` in this method  and call
>> 
>>     synchronized (p) {
>>        blockingReceive(p, ...);
>>     }
>> 
>> 
>> In the adaptor instead, like it used to be before virtual threads came into the picture?
>
> Not this PR but there is a follow-up coming that will drop the dependency on DatagramPacket from DatagramChannelImpl so that it does back to the adaptor.

OK - if you have follow-ups in the pipe to fix this then good to go!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840556553

From bpb at openjdk.org  Wed Nov 13 16:13:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 16:13:28 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>
Message-ID: <0rIvpI9LKcevQoyiQq5u8b5jGZPLJE8MBNwsw4NpcMY=.58ed3393-37e5-4990-813b-5d66ea2fd3e8@github.com>

On Wed, 13 Nov 2024 09:57:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343785: Use file descriptor in preference to path; add AIX to test @requires
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 80:
> 
>> 78:             // if path is a symlink, then the open should fail with ELOOP and
>> 79:             // the path will be used instead of the file descriptor.
>> 80:             boolean haveFd = false;
> 
> In passing, we don't need haveFd, instead we can use fd >= 0 as is done in other places.

Yes, I had thought of ding that but left `haveFd` as it had been there before. Will change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1840717319

From bpb at openjdk.org  Wed Nov 13 16:13:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 16:13:29 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <esKlBFFQbMdr0Q-Df3SnogHe3tbrqoFDxk2zIANCW64=.cc52090d-2547-4bcf-b055-52f24047b357@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>
 <slfUlLv5d75Xl2zmpr9DaQHR0Ct-YKDvmPveM6-q-yA=.4c55e951-b5d4-4417-9d68-a0cf1444f92b@github.com>
 <esKlBFFQbMdr0Q-Df3SnogHe3tbrqoFDxk2zIANCW64=.cc52090d-2547-4bcf-b055-52f24047b357@github.com>
Message-ID: <eZVoQxsWR_J6vzS2u4ExkKIa7-Wvx_b6-GUl6P31Yqw=.40e1d510-de28-44bd-aa1b-134842677755@github.com>

On Wed, 13 Nov 2024 11:56:38 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Yes, I think `@requires` can be dropped now.
>
> Yes, the test has passed on AIX.

I will delete the `@requires` tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1840715923

From alanb at openjdk.org  Wed Nov 13 16:53:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 16:53:49 GMT
Subject: Integrated: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
Message-ID: <pVtlwI3IbUosb-9qOCrfZpXTPjDACXIv0_ERn86Bnt0=.9b405afd-6b61-4098-9fff-231195147438@github.com>

On Wed, 13 Nov 2024 14:07:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from DatagramChannelImpl. Dropping this execution mode means that untrustedReceive can be removed. Additionally, blockingReceive (used to support the adaptor) no longer needs a loop to drop datagrams that the SecurityManager rejects.
> 
> Once this change is in then it allow reverting some changes introduced to avoid pinning in the adaptor's receive method, a consequence of have both JEP 486 and JEP 491 integrated.

This pull request has now been integrated.

Changeset: 7be77725
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7be77725eab6f45d8f8d23f2ba0d18d2d89a40aa
Stats:     206 lines in 2 files changed: 4 ins; 168 del; 34 mod

8344112: Remove code to support security manager execution mode from DatagramChannel implementation

Reviewed-by: dfuchs

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

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

From alanb at openjdk.org  Wed Nov 13 16:53:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 16:53:48 GMT
Subject: RFR: 8344112: Remove code to support security manager execution
 mode from DatagramChannel implementation
In-Reply-To: <EnubevSFfLNv2T17lVNO8JAiK8bzqVkvl8TPFxkWRYA=.32a5f28c-bd8c-4249-bd66-179d4aefcd02@github.com>
References: <0G-NIVpuXy-qrUUofA7vhj5ElgbX2bv1JFkfAPVekvQ=.4db4479e-9544-48b1-8a84-0e0750525c0d@github.com>
 <ldOgAs0wU-14C-NlI25k34cglU0E6n7O2eQAeH4IsPs=.20d3af3d-93a7-4588-a0cf-6041df513ccd@github.com>
 <_NPO_M0DGyNrGNQZcI51YrkMoo4sy0NUGDc0AclcAIg=.9ba3f610-2bf6-4ba2-bab4-48d80108c744@github.com>
 <EnubevSFfLNv2T17lVNO8JAiK8bzqVkvl8TPFxkWRYA=.32a5f28c-bd8c-4249-bd66-179d4aefcd02@github.com>
Message-ID: <KbXraa2MdsPS2wlLBFECmWbzJlkDQhoj5FCHAy3tCEU=.5b668ab2-08ca-4e15-a6bd-347643dbc89d@github.com>

On Wed, 13 Nov 2024 15:16:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Not this PR but there is a follow-up coming that will drop the dependency on DatagramPacket from DatagramChannelImpl so that it does back to the adaptor.
>
> OK - if you have follow-ups in the pipe to fix this then good to go!

Yes, there will be a follow-up from JEP 491 so that we can go back to using synchronization in the adaptor send/receive methods. I initially had everything in one patch but it's large so decided to split it and address the SM removal first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22072#discussion_r1840814042

From bpb at openjdk.org  Wed Nov 13 19:41:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:41:32 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v3]
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <MiXVVQpRVOnqriW5nzWpK0mnuhwDPlx_91s87QonMnQ=.37d550cc-ee53-422e-a677-dd3fbcea560d@github.com>

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

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

  8343785: haveFd -> fd >= 0; remove @requires fromfrom test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21989/files
  - new: https://git.openjdk.org/jdk/pull/21989/files/ef3d0a45..fc5f8e89

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

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

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

From bpb at openjdk.org  Wed Nov 13 19:41:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:41:32 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v3]
In-Reply-To: <cH3DwJClXord2RXkukaC9_6gcr4qDtebS8qClS2il6Y=.a471feba-dd81-4237-9f93-2128fc5fe5b8@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <cH3DwJClXord2RXkukaC9_6gcr4qDtebS8qClS2il6Y=.a471feba-dd81-4237-9f93-2128fc5fe5b8@github.com>
Message-ID: <zhiQfIFnau8NBu3e_EpY0gwHGF8qh0AxkhBrW7CVYzE=.47b3451c-251c-4e43-9cdc-d0baedb87426@github.com>

On Tue, 12 Nov 2024 19:25:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343785: haveFd -> fd >= 0; remove @requires fromfrom test
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 106:
> 
>> 104:             try {
>> 105:                 setattrlist(path, commonattr, 0L, 0L, createValue,
>> 106:                     followLinks ?  0 : UnixConstants.FSOPT_NOFOLLOW);
> 
> Suggestion:
> 
>                     followLinks ? 0 : UnixConstants.FSOPT_NOFOLLOW);

Cleaned up in fc5f8e8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1841059726

From bpb at openjdk.org  Wed Nov 13 19:41:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:41:33 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <0rIvpI9LKcevQoyiQq5u8b5jGZPLJE8MBNwsw4NpcMY=.58ed3393-37e5-4990-813b-5d66ea2fd3e8@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <cqlzduzdAql2z1LirI3c45QYDKFge3-CLH8_vRnpB-w=.d68aac90-ea31-4556-9a3c-d50502d4210e@github.com>
 <0rIvpI9LKcevQoyiQq5u8b5jGZPLJE8MBNwsw4NpcMY=.58ed3393-37e5-4990-813b-5d66ea2fd3e8@github.com>
Message-ID: <TnTRSc5ux-v2lsiasE4NHdsPGj4jrl7riPqKL24mWzM=.1e05c6be-ca41-4363-8ffc-37acb333a74e@github.com>

On Wed, 13 Nov 2024 16:10:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 80:
>> 
>>> 78:             // if path is a symlink, then the open should fail with ELOOP and
>>> 79:             // the path will be used instead of the file descriptor.
>>> 80:             boolean haveFd = false;
>> 
>> In passing, we don't need haveFd, instead we can use fd >= 0 as is done in other places.
>
> Yes, I had thought of doing that but left `haveFd` as it had been there before. Will change.

`s/haveFd/fd >= 0/` in fc5f8e8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1841060854

From bpb at openjdk.org  Wed Nov 13 19:41:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:41:33 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v2]
In-Reply-To: <eZVoQxsWR_J6vzS2u4ExkKIa7-Wvx_b6-GUl6P31Yqw=.40e1d510-de28-44bd-aa1b-134842677755@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <wSPDYfqCPDE4wDCRIWft80lZ8nu7QcKcP9WmXkgLHEY=.aee3d336-365c-4833-9828-4275e9ac8710@github.com>
 <dQEDl2gxD3Pk09w4ZENUb6ayyCqtMDUhehMyVrRLraI=.f2049a4c-0b9e-4ddb-8cd0-85e15a294773@github.com>
 <slfUlLv5d75Xl2zmpr9DaQHR0Ct-YKDvmPveM6-q-yA=.4c55e951-b5d4-4417-9d68-a0cf1444f92b@github.com>
 <esKlBFFQbMdr0Q-Df3SnogHe3tbrqoFDxk2zIANCW64=.cc52090d-2547-4bcf-b055-52f24047b357@github.com>
 <eZVoQxsWR_J6vzS2u4ExkKIa7-Wvx_b6-GUl6P31Yqw=.40e1d510-de28-44bd-aa1b-134842677755@github.com>
Message-ID: <KPm4y-QK9Fau0uQwHu9xZErnlAunGsdH0b4ryYydEvM=.dd8360ac-14da-49a8-8149-48b4c25d6bea@github.com>

On Wed, 13 Nov 2024 16:10:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes, the test has passed on AIX.
>
> I will delete the `@requires` tag.

`@requires` deleted in fc5f8e8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21989#discussion_r1841060190

From alanb at openjdk.org  Wed Nov 13 20:39:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 20:39:33 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v3]
In-Reply-To: <MiXVVQpRVOnqriW5nzWpK0mnuhwDPlx_91s87QonMnQ=.37d550cc-ee53-422e-a677-dd3fbcea560d@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <MiXVVQpRVOnqriW5nzWpK0mnuhwDPlx_91s87QonMnQ=.37d550cc-ee53-422e-a677-dd3fbcea560d@github.com>
Message-ID: <8yQBxX_3nacHrtwh6OSgMXXmPDfairowtNyp4Voz_-Q=.d1bdbb76-7dee-407a-843d-cb40b2702f90@github.com>

On Wed, 13 Nov 2024 19:41:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343785: haveFd -> fd >= 0; remove @requires fromfrom test

Update looks okay, I assume you'll run tier1+tier2 at least before integrating.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21989#pullrequestreview-2434358114

From bpb at openjdk.org  Wed Nov 13 20:39:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:39:33 GMT
Subject: RFR: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision [v3]
In-Reply-To: <8yQBxX_3nacHrtwh6OSgMXXmPDfairowtNyp4Voz_-Q=.d1bdbb76-7dee-407a-843d-cb40b2702f90@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
 <MiXVVQpRVOnqriW5nzWpK0mnuhwDPlx_91s87QonMnQ=.37d550cc-ee53-422e-a677-dd3fbcea560d@github.com>
 <8yQBxX_3nacHrtwh6OSgMXXmPDfairowtNyp4Voz_-Q=.d1bdbb76-7dee-407a-843d-cb40b2702f90@github.com>
Message-ID: <I_8J19Wikm6V0HkJm5SpyNyY47VjxSgYdzr-zseufHE=.c114df0d-ad27-4e3b-b6c7-00955303b80a@github.com>

On Wed, 13 Nov 2024 20:35:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I assume you'll run tier1+tier2 at least before integrating.

Usually tiers 1-3 on several platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/21989#issuecomment-2474734075

From swen at openjdk.org  Wed Nov 13 23:21:51 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 13 Nov 2024 23:21:51 GMT
Subject: Integrated: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <tRKVTDkB3E2Kxcr3K0nZZ4WTv9GrU_gv0wYgOXT0Y0E=.7e999494-1ed2-4985-9fe9-4d0d2de14852@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

This pull request has now been integrated.

Changeset: 0dab920b
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0dab920b70560a5aea8b068080655a292908b646
Stats:     34 lines in 11 files changed: 0 ins; 0 del; 34 mod

8343984: Fix Unsafe address overflow

Reviewed-by: pminborg, alanb

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

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

From swen at openjdk.org  Thu Nov 14 05:47:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 14 Nov 2024 05:47:12 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
Message-ID: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>

The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.

@liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

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

Commit messages:
 - long Unsafe offset

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

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

From eirbjo at openjdk.org  Thu Nov 14 11:29:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 11:29:41 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
Message-ID: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>

Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.

* `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
* `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
*  The test `TestPosix` is updated to perform `AccessController.doPrivileged`

This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.

Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

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

Commit messages:
 - Cleanup SM-dependent code in the ZipFs area

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

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

From lancea at openjdk.org  Thu Nov 14 14:07:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 14:07:31 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>

On Thu, 14 Nov 2024 11:21:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

Thank you for the PR Eirik, overall it looks OK.  See comments below WRT to exception messages in the test

test/jdk/jdk/nio/zipfs/TestPosix.java line 224:

> 222:         } catch (IOException e) {
> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
> 224:                     ") when running a privileged operation to get the default owner.");

Given we are not running a privileged operation, we should probably tweak the exception message

test/jdk/jdk/nio/zipfs/TestPosix.java line 239:

> 237:             return defaultOwner;
> 238:         } catch (IOException e) {
> 239:             System.out.println("Caught an exception when running a privileged operation to get the default group.");

Same comment WRT "privileged operation"

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

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2436170504
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842273651
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842274986

From eirbjo at openjdk.org  Thu Nov 14 14:15:28 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:15:28 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
Message-ID: <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>

On Thu, 14 Nov 2024 14:01:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 224:
> 
>> 222:         } catch (IOException e) {
>> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
>> 224:                     ") when running a privileged operation to get the default owner.");
> 
> Given we are not running a privileged operation, we should probably tweak the exception message

Thanks, I was a bit of a robot here and didn't read the exception message :-)

I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842289557

From lancea at openjdk.org  Thu Nov 14 14:34:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 14:34:25 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
 <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
Message-ID: <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>

On Thu, 14 Nov 2024 14:11:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/TestPosix.java line 224:
>> 
>>> 222:         } catch (IOException e) {
>>> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
>>> 224:                     ") when running a privileged operation to get the default owner.");
>> 
>> Given we are not running a privileged operation, we should probably tweak the exception message
>
> Thanks, I was a bit of a robot here and didn't read the exception message :-)
> 
> I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.
> 
> What do you think?

For this specific PR, I might just change the error message and revisit once we deal with the SM to avoid any unexpected surprises (one bitten twice shy ;-) )

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842323725

From eirbjo at openjdk.org  Thu Nov 14 14:43:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:43:50 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

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

  Update debug logging to not reference privileged operations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22101/files
  - new: https://git.openjdk.org/jdk/pull/22101/files/d8936a5c..37104a91

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

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

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

From eirbjo at openjdk.org  Thu Nov 14 14:43:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:43:50 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
 <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
 <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>
Message-ID: <kOopkDSgmViIYeVWjg2rfczeI3iBl5A0JpQF5v9ikgo=.d00f4446-cc4b-4efa-b959-cb308ddb46fd@github.com>

On Thu, 14 Nov 2024 14:31:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Thanks, I was a bit of a robot here and didn't read the exception message :-)
>> 
>> I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.
>> 
>> What do you think?
>
> For this specific PR, I might just change the error message and revisit once we deal with the SM to avoid any unexpected surprises (one bitten twice shy ;-) )

Okay, I've tweaked the debug messages to not reference privileged actions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842339786

From lancea at openjdk.org  Thu Nov 14 15:04:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 15:04:38 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
Message-ID: <gTkaHj9td9gnqmv8Oop9dWp98Z74QoN8fWaNL4_WyRw=.026ef8f1-3145-4385-b7e2-316f3c9997e5@github.com>

On Thu, 14 Nov 2024 14:43:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update debug logging to not reference privileged operations

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2436338832

From mullan at openjdk.org  Thu Nov 14 16:01:53 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 16:01:53 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
Message-ID: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>

On Thu, 14 Nov 2024 14:43:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update debug logging to not reference privileged operations

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 252:

> 250:         if (o == null) {
> 251:             try {
> 252:                 PrivilegedExceptionAction<UserPrincipal> pa = ()->Files.getOwner(zfpath);

Can you also remove the `@SuppressWarnings("removal")` on line 239?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 294:

> 292:                     return defaultOwner::getName;
> 293:                 }
> 294:                 PrivilegedExceptionAction<GroupPrincipal> pa = ()->zfpv.readAttributes().group();

Can you also remove the @SuppressWarnings("removal") on line 269?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 483:

> 481:         beginWrite();                // lock and sync
> 482:         try {
> 483:             AccessController.doPrivileged((PrivilegedExceptionAction<Void>)() -> {

Can you also remove the @SuppressWarnings("removal") on line 442?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 317:

> 315: 
> 316:     //////////////////////////////////////////////////////////////
> 317:     @SuppressWarnings("removal")

You can remove the annotation now.

test/jdk/jdk/nio/zipfs/TestPosix.java line 236:

> 234:             }
> 235:             return zfpv.readAttributes().group().getName();
> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {

In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842463056
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842467210
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842466546
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842445637
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842456357

From bpb at openjdk.org  Thu Nov 14 16:30:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Nov 2024 16:30:26 GMT
Subject: Integrated: 8343785: (fs) Remove syscalls that set file times with
 microsecond precision
In-Reply-To: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
References: <yxlzgTLkHazl6AtquYW3-673UNYSgHvpDSlA4h16Xl8=.789f949b-29c4-4369-a82d-3bf5526cdbbe@github.com>
Message-ID: <1TpHIxeEgDA82euxdDZVuo4_scdjtpMWRXJGWntCsxI=.8e444583-3517-4412-bd3d-73ed6ba1027c@github.com>

On Fri, 8 Nov 2024 16:18:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove the syscalls `utimes`, `futimes`, and `lutimes` that set the file access and modification times using microsecond precision.

This pull request has now been integrated.

Changeset: 7e9dfa4a
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e9dfa4ae4bbafadd2f31fa31df9f25250847200
Stats:     333 lines in 7 files changed: 29 ins; 245 del; 59 mod

8343785: (fs) Remove syscalls that set file times with microsecond precision

Reviewed-by: alanb

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

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

From eirbjo at openjdk.org  Thu Nov 14 17:01:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:48 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

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

 - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
 - Remove @SuppressWarnings("removal")

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22101/files
  - new: https://git.openjdk.org/jdk/pull/22101/files/37104a91..c13e5519

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

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

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

From eirbjo at openjdk.org  Thu Nov 14 17:01:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:49 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
Message-ID: <XVVemab-eMvwilig-QhiH-EqxEfI3g_56pG6LZWvatY=.945297fc-5ed9-46b1-b086-3167b08ef649@github.com>

On Thu, 14 Nov 2024 15:52:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
>>  - Remove @SuppressWarnings("removal")
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 252:
> 
>> 250:         if (o == null) {
>> 251:             try {
>> 252:                 PrivilegedExceptionAction<UserPrincipal> pa = ()->Files.getOwner(zfpath);
> 
> Can you also remove the `@SuppressWarnings("removal")` on line 239?

Removed this and the others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842588438

From eirbjo at openjdk.org  Thu Nov 14 17:01:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:51 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
Message-ID: <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>

On Thu, 14 Nov 2024 15:48:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update debug logging to not reference privileged operations
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 236:
> 
>> 234:             }
>> 235:             return zfpv.readAttributes().group().getName();
>> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {
> 
> In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.

Interesting catch..

My understanding is that the purpose of `expectedDefaultOwner` and `expectedDefaultGroup` is to mimic the behavior of `ZipFileSystem:initOwner` and `ZipFileSystem::initGroup`.

The ZipFileSystem methods both check for `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, while the TestPosix expect methods do not. This is why I added them, to make them consistent with the implementation code.

This inconsistency is a however a preexisting issue. Attempting to fixing them here might just clutter this review. So I have reverted the catch for `NoSuchFileException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842587185

From mullan at openjdk.org  Thu Nov 14 19:25:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 19:25:47 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>
Message-ID: <Rh3Zab3deNDgngmR-7_ZRR7FHN-5ZfovAnOYa1Tml0c=.fa6c605b-a017-4858-98de-1cf4ccbe7b2b@github.com>

On Thu, 14 Nov 2024 17:01:48 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
>  - Remove @SuppressWarnings("removal")

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2437010891

From mullan at openjdk.org  Thu Nov 14 19:25:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 19:25:49 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
 <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
Message-ID: <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>

On Thu, 14 Nov 2024 16:56:00 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/TestPosix.java line 236:
>> 
>>> 234:             }
>>> 235:             return zfpv.readAttributes().group().getName();
>>> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {
>> 
>> In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.
>
> Interesting catch..
> 
> My understanding is that the purpose of `expectedDefaultOwner` and `expectedDefaultGroup` is to mimic the behavior of `ZipFileSystem:initOwner` and `ZipFileSystem::initGroup`.
> 
> The ZipFileSystem methods both check for `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, while the TestPosix expect methods do not. This is why I added them, to make them consistent with the implementation code.
> 
> This inconsistency is a however a preexisting issue. Attempting to fixing them here might just clutter this review. So I have reverted the catch for `NoSuchFileException`.

Ok, but your change did not check `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, it just checked if the exception was `NoSuchFileException`.

In any case, I agree, best to preserve the existing code as much as possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842774624

From eirbjo at openjdk.org  Thu Nov 14 19:40:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 19:40:12 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
 <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
 <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>
Message-ID: <GKXm1GuyfXwrh759_RyW7qWylxOfxtoTULnR9hZW3CI=.dd123356-31c0-4bc5-9ddb-50d0f7e3b60e@github.com>

On Thu, 14 Nov 2024 19:21:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Ok, but your change did not check `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, it just checked if the exception was `NoSuchFileException`.

For the record, there was a typo in my comment, I meant to say `PrivilegedActionException. getCause() instanceof ..`.

...but yes, this doesn't matter now that we agree to not fix this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842793434

From bpb at openjdk.org  Fri Nov 15 05:42:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 05:42:28 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
Message-ID: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>

Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

Commit messages:
 - 8344078: Remove security manager dependency in java.nio

Changes: https://git.openjdk.org/jdk/pull/22132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344078
  Stats: 1318 lines in 63 files changed: 9 ins; 1082 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/22132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22132/head:pull/22132

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

From bpb at openjdk.org  Fri Nov 15 05:42:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 05:42:28 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <mJ-XNwKbv1t2OUPwtFCC3MkvQ7eUeN_ExOESTuiOEzQ=.6f1de164-d6d3-492a-bf0d-d26ae6abf21f@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

The `test/jdk/:tier{1,2,3}` jobs passed on all three operating systems.

The Windows version of `sun.nio.ch.PipeImpl` could use some refactoring but this is deferred to a future commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22132#issuecomment-2478001046

From eirbjo at openjdk.org  Fri Nov 15 07:51:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 07:51:52 GMT
Subject: Integrated: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <wAKdtQAVVDLCCDbeFLiHvkc9q_Ek7F-bqdFVyVULQfQ=.ebc10952-ebc0-4e16-8ac9-cba37c7e6bf0@github.com>

On Thu, 14 Nov 2024 11:21:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

This pull request has now been integrated.

Changeset: bfee766f
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfee766f035fb1b122cd3f3703b9e2a2d85abfe6
Stats:     85 lines in 3 files changed: 3 ins; 57 del; 25 mod

8344183: (zipfs) SecurityManager cleanup in the ZipFS area

Reviewed-by: mullan, lancea

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

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

From alanb at openjdk.org  Fri Nov 15 08:13:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 08:13:18 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <wjVzGCfBBQMB8V-Xmdk8bldp4spS1P5uNUz5X73_Ov0=.36c20b26-3eb6-407a-bf1b-b657939864db@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

CopyMoveHelper needs to be updated too.

src/java.base/linux/classes/sun/nio/ch/DefaultSelectorProvider.java line 34:

> 32: public class DefaultSelectorProvider {
> 33:     private static final SelectorProviderImpl INSTANCE =
> 34:         new EPollSelectorProvider();

You should be able to put it on the same line, same thing in the other implementations.

src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java line 116:

> 114:                     return i.hasNext() ? i.next() : null;
> 115:                 } catch (ServiceConfigurationError sce) {
> 116:                     throw sce;

There's no need to catch ServiceConfigurationError now, same thing in AsynchronousChannelProvider, Charset ...

src/java.base/share/classes/java/nio/file/FileTreeWalker.java line 206:

> 204:         // if attributes are cached then use them if possible
> 205:         if (canUseCached &&
> 206:             (file instanceof BasicFileAttributesHolder))

We can replace this with `if ((canUseCached && (file instanceof BasicFileAttributesHolde holder) {` and it would make it a lot more readable.

src/java.base/share/classes/sun/nio/ch/Net.java line 218:

> 216:      * Returns the local address
> 217:      */
> 218:     static InetSocketAddress getRevealedLocalAddress(SocketAddress sa) {

This method should be removed.

src/java.base/share/classes/sun/nio/ch/Net.java line 223:

> 221:     }
> 222: 
> 223:     static String getRevealedLocalAddressAsString(SocketAddress sa) {

This method should be removed too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22132#issuecomment-2478190884
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843321219
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843325337
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843337667
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843326286
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843326483

From alanb at openjdk.org  Fri Nov 15 08:28:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 08:28:01 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <taO9rF0GEe1hjGAynK491u25O0j3CqN8bWA0_g8MFWo=.1a5cf5d3-4c3f-453f-9e9b-4d1e826aae73@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

src/java.base/share/classes/sun/nio/fs/PollingWatchService.java line 131:

> 129:             throw new ClosedWatchServiceException();
> 130: 
> 131:         return doPrivilegedRegister(path, eventSet);

We can collapse this, no need for doPrivilegedRegister now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843369329

From alanb at openjdk.org  Fri Nov 15 08:43:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 08:43:30 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <n-nmzYG2FvsePxxYUa5MDXlxQvF1fLqpthZbNZf3LDQ=.66b7a8f4-6db9-4c7a-bb14-4d77fe1d4c00@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

> 180:         return new Iterable<>() {
> 181:             public Iterator<Path> iterator() {
> 182:                 return allowedList.iterator();

The method body can be replaced with `return List.of(rootDirectory);`.

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

> 284:                 return Collections.emptyList();
> 285:             }
> 286:         }

The method body can be replaced with `return FileStoreIterator::new;`.

src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 842:

> 840:         }
> 841:         // The path is relative so need to resolve against default directory,
> 842:         // taking care not to reveal the user.dir

Second part of the comment can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843383083
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843386323
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843379196

From alanb at openjdk.org  Fri Nov 15 08:51:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 08:51:28 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <Cd9Kh4NXF9jki2DW5mVr80kXjOJD8WBrndBaVzoq0cM=.8c4ef9ee-6023-42bf-a911-4bcf4580a258@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

src/java.base/share/classes/sun/nio/ch/Reflect.java line 45:

> 43: 
> 44:     private static void setAccessible(final AccessibleObject ao) {
> 45:         ao.setAccessible(true);

This method can be removed and lookupConstructor changed to call setAccessible.

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

> 250:                 sm.checkDelete(pathForPermissionCheck);
> 251:         }
> 252: 

The changes in this area need to go a bit deeper and remove the pathForPermissionCheck parameter from this method, the open method, and all the callers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843396382
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843393399

From alanb at openjdk.org  Fri Nov 15 09:05:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 09:05:59 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <htesBtJMVUToZwGg0ALhUs8xNnEyg6uLXQUShbvsFNQ=.1d8d6afa-02e3-4eb8-bd92-7372c9cdf12f@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java line 62:

> 60:     }
> 61: 
> 62:     static UnixDomainSocketAddress getRevealedLocalAddress(SocketAddress sa) {

This method can be removed.

src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java line 74:

> 72:     private static native byte[] localAddress0(FileDescriptor fd) throws IOException;
> 73: 
> 74:     static String getRevealedLocalAddressAsString(SocketAddress sa) {

This method can be removed, replace with toString at the use-site.

src/java.base/windows/classes/sun/nio/ch/PipeImpl.java line 65:

> 63: 
> 64:     private static class Initializer
> 65:     {

The "{" can move back to the previous line now.

src/java.base/windows/classes/sun/nio/fs/WindowsChannelFactory.java line 307:

> 305:             }
> 306:         }
> 307: 

I assume the pathToCheck parameter should be removed from newFileChannel and open methods.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java line 197:

> 195:                 return Collections.emptyList();
> 196:             }
> 197:         }

I assume this can just be replaced with `return FileStoreIterator::new;`.

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 916:

> 914:         }
> 915:     }
> 916: 

I assume getPathForPermissionCheck() should be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843401197
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843400845
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843417289
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843404057
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843405995
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843408457

From alanb at openjdk.org  Fri Nov 15 09:11:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 09:11:21 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <r6BDbn6PCAS2INHNI6PoWouKt8O3rS8uTTLONmo6s5I=.317a658d-2587-4d60-81ab-a1697fb522fb@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

There is a lot of changes in this PR, covering several areas. Overall a good cleanup. I spotted a number of things going through this, hopefully my comments are clear.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystem.java line 107:

> 105:         ArrayList<Path> result = new ArrayList<>();
> 106:         @SuppressWarnings("removal")
> 107:         SecurityManager sm = System.getSecurityManager();

"ignoring those that the security manager denies"  can be removed from the method description.

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2438039750
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1843422786

From bpb at openjdk.org  Fri Nov 15 16:18:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 16:18:57 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <r6BDbn6PCAS2INHNI6PoWouKt8O3rS8uTTLONmo6s5I=.317a658d-2587-4d60-81ab-a1697fb522fb@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <r6BDbn6PCAS2INHNI6PoWouKt8O3rS8uTTLONmo6s5I=.317a658d-2587-4d60-81ab-a1697fb522fb@github.com>
Message-ID: <lFmK1TyshP6R3eM1EaJInPZdEJZJJIMjt3XnWNBDnqI=.024cd033-4de9-4372-95d3-8709a7f3af3c@github.com>

On Fri, 15 Nov 2024 09:07:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There is a lot of changes in this PR, covering several areas. Overall a good cleanup.

Thanks.

> I spotted a number of things going through this, hopefully my comments are clear.

Your comments are clear. I was sure there would be some things missed or incomplete, including some of the suggested changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22132#issuecomment-2479335388

From bpb at openjdk.org  Fri Nov 15 16:38:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 16:38:09 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v2]
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

  8344078: Update overlooked CopyMoveHelper and CompletedFuture

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22132/files
  - new: https://git.openjdk.org/jdk/pull/22132/files/391c0329..05bc2c96

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

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

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

From duke at openjdk.org  Fri Nov 15 17:02:00 2024
From: duke at openjdk.org (duke)
Date: Fri, 15 Nov 2024 17:02:00 GMT
Subject: Withdrawn: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException
In-Reply-To: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
Message-ID: <m-K5XMRDebk_-WfHlqeFR24kvk3DCzS18xbkGdc74LM=.157018dc-98eb-4585-a4c3-1e12265e20fc@github.com>

On Fri, 13 Sep 2024 07:00:24 GMT, xpbob <duke at openjdk.org> wrote:

> (fs) Files.copy include symbolic link detailed message for NoSuchFileException
> 
> Description
> Simulation case:
> 
> touch testfile
> ln -s testfile testlink
> mv testfile testfile1
> 
> 
> code:
> 
>     public static void main(String[] args) throws IOException {
>         Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx"));
>     }
> 
> 
> Program current information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink
> 
> 
> Devops check file exists with ll
> 
> After additional information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Fri Nov 15 17:33:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 17:33:52 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v2]
In-Reply-To: <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
Message-ID: <gC9o217isV875jYksiKtlObUtK9bWhu80Hh-lZwmu6I=.c6cd07f7-c892-41fa-92cf-711417f5dfeb@github.com>

On Fri, 15 Nov 2024 16:38:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Update overlooked CopyMoveHelper and CompletedFuture

Looked at charset related changes (Charset.java/CharsetMapping.java). Looks good overall with one minor comment.

src/java.base/share/classes/java/nio/charset/Charset.java line 371:

> 369:                                 // Ignore security exceptions
> 370:                                 continue;
> 371:                             }

Removing this part makes the comment (L347-349) moot.

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2439237162
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844218817

From rriggs at openjdk.org  Fri Nov 15 17:33:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 17:33:53 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v2]
In-Reply-To: <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
Message-ID: <nhlH4UHDzXD3r637kqB77nATtGAj2ckKg0nbqXAy2B8=.1b109264-3938-483a-a221-b23ada8d6e67@github.com>

On Fri, 15 Nov 2024 16:38:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Update overlooked CopyMoveHelper and CompletedFuture

src/java.base/share/classes/java/nio/charset/Charset.java line 368:

> 366:                             next = i.next();
> 367:                         } catch (ServiceConfigurationError sce) {
> 368:                             if (sce.getCause() instanceof SecurityException) {

No need for catch (since rethrown)

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

> 1526:                 list.add(detector);
> 1527:             }
> 1528:             return list;

Possible refactor to use stream API:  (may be a bit too aggressive)
Suggestion:

             return ServiceLoader
                    .load(FileTypeDetector.class, ClassLoader.getSystemClassLoader())
                    .stream()
                    .map(p -> (FileTypeDetector)p).toList();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844166492
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844185396

From bpb at openjdk.org  Fri Nov 15 18:04:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 18:04:02 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v2]
In-Reply-To: <nhlH4UHDzXD3r637kqB77nATtGAj2ckKg0nbqXAy2B8=.1b109264-3938-483a-a221-b23ada8d6e67@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
 <nhlH4UHDzXD3r637kqB77nATtGAj2ckKg0nbqXAy2B8=.1b109264-3938-483a-a221-b23ada8d6e67@github.com>
Message-ID: <B1W2eGE0Mk3oMsuNBGv3yduFsA5QmYziFi1Tevmpjek=.c998c164-38cd-4465-9213-eda6ec1c6cfb@github.com>

On Fri, 15 Nov 2024 17:03:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Update overlooked CopyMoveHelper and CompletedFuture
>
> src/java.base/share/classes/java/nio/file/Files.java line 1528:
> 
>> 1526:                 list.add(detector);
>> 1527:             }
>> 1528:             return list;
> 
> Possible refactor to use stream API:  (may be a bit too aggressive)
> Suggestion:
> 
>              return ServiceLoader
>                     .load(FileTypeDetector.class, ClassLoader.getSystemClassLoader())
>                     .stream()
>                     .map(p -> (FileTypeDetector)p).toList();

Thanks for the suggestion. Perhaps in a later commit: I would prefer to keep the initial changes closed to the original.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844265182

From naoto at openjdk.org  Fri Nov 15 19:32:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 19:32:05 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from jdk.charsets
 module
Message-ID: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>

Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

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

Commit messages:
 - initial commit

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

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

From lancea at openjdk.org  Fri Nov 15 19:35:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 15 Nov 2024 19:35:55 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <lvdNwtr7eBc1bqhPXa89G9EZLNb7rLPhzXM2rxaIycs=.1ae64177-3d95-4044-b2fd-b69a7e594448@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439458103

From bpb at openjdk.org  Fri Nov 15 19:41:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 19:41:48 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <aUCgEKWaQo4QZ_kVrd6RwdqtTLu8uF3T4CQpg5qu270=.cabd94dc-f2ff-446b-b55b-957ebab33339@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439470029

From naoto at openjdk.org  Fri Nov 15 20:17:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 20:17:59 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

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

  fixed import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22162/files
  - new: https://git.openjdk.org/jdk/pull/22162/files/ebd0523f..03d25e8f

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

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

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

From rriggs at openjdk.org  Fri Nov 15 20:17:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 20:17:59 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <KDfDQ0yMi-H3O7fVwMHkOVryETpEYG1dNAwfqH2bqsw=.fe6a54e5-93d3-4979-82f2-e2e1438136d4@github.com>

On Fri, 15 Nov 2024 20:15:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439536041

From bpb at openjdk.org  Fri Nov 15 23:15:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 23:15:53 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <u7ix4dvk3Q-rCODNCtmONmzuVdK36IqG1ITYCTLxBkY=.743d5508-52f9-4d92-a724-7c578e6bb2ce@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Updated version looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439914323

From lancea at openjdk.org  Sat Nov 16 00:06:42 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 16 Nov 2024 00:06:42 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <fti-qykjyUPhLPAHCtflVlp5R8-ohdNwamRgOcicmkU=.0ba22560-082d-43a8-b83a-b1a6ac0aecf7@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439986238

From bpb at openjdk.org  Sat Nov 16 00:22:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Nov 2024 00:22:44 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: <AbO3igd_qHtGwU8fRIcZPitY8cvItbMX4ZdA5Edg-BE=.2fa9c25f-2b86-44dc-b38b-869c79f60169@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

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2480197204

From bpb at openjdk.org  Sat Nov 16 00:33:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Nov 2024 00:33:13 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

  8344078: Address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22132/files
  - new: https://git.openjdk.org/jdk/pull/22132/files/05bc2c96..c1c348f7

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

  Stats: 163 lines in 34 files changed: 0 ins; 109 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/22132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22132/head:pull/22132

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

From naoto at openjdk.org  Sat Nov 16 00:33:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 16 Nov 2024 00:33:13 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <PfY3w0e0cJOZ4eNLy3WQlkrcO5h15u7gPTrXjwIrTnc=.c594d705-316c-4c45-9e3f-64f30d649804@github.com>

On Sat, 16 Nov 2024 00:30:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

Looks good for those two Charset related files.

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2440005589

From bpb at openjdk.org  Sat Nov 16 00:33:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Nov 2024 00:33:13 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v2]
In-Reply-To: <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
Message-ID: <cpkgU6Ep2xU3mOhP515yUHHEvGoBYSRzgdkcIiuBvIY=.a4c4283a-93f7-4b1a-bb37-607a1013138e@github.com>

On Fri, 15 Nov 2024 16:38:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Update overlooked CopyMoveHelper and CompletedFuture

Commit c1c348f addresses all resolved conversations above.

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

PR Comment: https://git.openjdk.org/jdk/pull/22132#issuecomment-2480207914

From bpb at openjdk.org  Sat Nov 16 00:33:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Nov 2024 00:33:14 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <wjVzGCfBBQMB8V-Xmdk8bldp4spS1P5uNUz5X73_Ov0=.36c20b26-3eb6-407a-bf1b-b657939864db@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <wjVzGCfBBQMB8V-Xmdk8bldp4spS1P5uNUz5X73_Ov0=.36c20b26-3eb6-407a-bf1b-b657939864db@github.com>
Message-ID: <MRkRTDLITCka-T6cp9iJqUMAxrdruYW7QtFc9o1NCrc=.fcb92b0b-ec6c-42a9-bfff-e8f25a082df2@github.com>

On Fri, 15 Nov 2024 07:55:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Address reviewer comments
>
> src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java line 116:
> 
>> 114:                     return i.hasNext() ? i.next() : null;
>> 115:                 } catch (ServiceConfigurationError sce) {
>> 116:                     throw sce;
> 
> There's no need to catch ServiceConfigurationError now, same thing in AsynchronousChannelProvider, Charset ...

Several methods in `FileSystems` are still documented as throwing `ServiceConfigurationError`. Need to verify whether this is still accurate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844724423

From jlu at openjdk.org  Sat Nov 16 01:05:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 16 Nov 2024 01:05:41 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <k1lmU1CEpzVUOACEOjyLTdIAEosMQ7iquvYwnPH2r8Y=.91b8d6e9-49c8-4108-8387-9188beda51ab@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2440013905

From duke at openjdk.org  Sat Nov 16 06:17:49 2024
From: duke at openjdk.org (Glavo)
Date: Sat, 16 Nov 2024 06:17:49 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <t0yQ1Llj6V4e-y_-uwtz0JsLUQqyiQhj1y5bDzJGxmY=.0419db17-40b7-4e22-b589-481ba59091ce@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

src/java.base/share/classes/java/nio/charset/Charset.java line 416:

> 414:         try {
> 415:             for (Iterator<CharsetProvider> i = providers();
> 416:                  i.hasNext();) {

Suggestion:

            for (Iterator<CharsetProvider> i = providers(); i.hasNext();) {


No more line breaks are needed here.

src/java.base/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java line 48:

> 46:     // thread pool. Internal threads do not dispatch to completion handlers.
> 47:     private static final int internalThreadCount =
> 48:         Integer.valueOf(System.getProperty("sun.nio.ch.internalThreadPoolSize", "1"));

Suggestion:

        Integer.getInteger("sun.nio.ch.internalThreadPoolSize", 1);

src/java.base/share/classes/sun/nio/ch/Invoker.java line 43:

> 41:     // avoid stack overflow and lessens the risk of starvation.
> 42:     private static final int maxHandlerInvokeCount =
> 43:         Integer.valueOf(System.getProperty("sun.nio.ch.maxCompletionHandlersOnStack", "16"));

Suggestion:

        Integer.getInteger("sun.nio.ch.maxCompletionHandlersOnStack", 16);


The behavior here changes when the value cannot be parsed as an integer.

`GetIntegerAction` uses `Integer.getInteger` to get the value. When the value cannot be parsed as an integer, it returns the default value instead of throwing `NumberFormatException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844917157
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844918982
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844918157

From alanb at openjdk.org  Sat Nov 16 08:33:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 08:33:48 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <MRkRTDLITCka-T6cp9iJqUMAxrdruYW7QtFc9o1NCrc=.fcb92b0b-ec6c-42a9-bfff-e8f25a082df2@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <wjVzGCfBBQMB8V-Xmdk8bldp4spS1P5uNUz5X73_Ov0=.36c20b26-3eb6-407a-bf1b-b657939864db@github.com>
 <MRkRTDLITCka-T6cp9iJqUMAxrdruYW7QtFc9o1NCrc=.fcb92b0b-ec6c-42a9-bfff-e8f25a082df2@github.com>
Message-ID: <0KxfTWFEk8yGVr2jfEFMyvbuSiSC7KVRNz_Aqa1QTN8=.1e2bb923-4783-4832-a729-59e7d20480b8@github.com>

On Sat, 16 Nov 2024 00:26:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java line 116:
>> 
>>> 114:                     return i.hasNext() ? i.next() : null;
>>> 115:                 } catch (ServiceConfigurationError sce) {
>>> 116:                     throw sce;
>> 
>> There's no need to catch ServiceConfigurationError now, same thing in AsynchronousChannelProvider, Charset ...
>
> Several methods in `FileSystems` are still documented as throwing `ServiceConfigurationError`. Need to verify whether this is still accurate.

Yes, it's still possible, the main thing here (and in a few places) is that we don't need to caught SCE to ignore a cause of SecurityException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844936876

From alanb at openjdk.org  Sat Nov 16 08:58:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 08:58:55 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <8Y-9XeQpJBF2sKux4t6kxX2Nnk2L2yfJfoZiBi0HAeI=.c4c0577a-ee8d-40da-a49b-f6173fa034a8@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

src/java.base/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java line 95:

> 93:             Iterator<AsynchronousChannelProvider> i = sl.iterator();
> 94:             for (;;) {
> 95:                 return (i.hasNext()) ? i.next() : null;

The loop was only required to filter SecurityException so you change this to `return sl.findFirst().orElse(null);`

src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java line 113:

> 111:             Iterator<SelectorProvider> i = sl.iterator();
> 112:             for (;;) {
> 113:                 return i.hasNext() ? i.next() : null;

Same thing as AsynchronousChannelProvider here, the loop goes away, it can be replaced with `return sl.findFirst().orElse(null);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844940028
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844940207

From alanb at openjdk.org  Sat Nov 16 09:02:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 09:02:55 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <HOic-3bSVekblCff96v22NJxVv27TLLv-uZVWnEKdRo=.4942b060-a740-41d3-bee3-863f80485373@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

src/java.base/share/classes/java/nio/file/FileTreeWalker.java line 205:

> 203:     {
> 204:         // if attributes are cached then use them if possible
> 205:         if (canUseCached && (file instanceof BasicFileAttributesHolder)) {

Maybe you don't want to do it in this PR but this can use pattern matching and avoid casting to BasicFileAttribtuesHolder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844940622

From alanb at openjdk.org  Sat Nov 16 09:06:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 09:06:55 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <ZK8FvxLXCkb0YI9uociLmhSjIJUoXVPF6z6UTtsQQqY=.ef5a7ca8-fa7f-4327-add2-b7d409ac4042@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

src/java.base/share/classes/sun/nio/fs/AbstractPoller.java line 62:

> 60:                                 false);
> 61:         thr.setDaemon(true);
> 62:         thr.start();

Not for this PR but we should replace this with an InnocuousThread at some point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844941191

From alanb at openjdk.org  Sat Nov 16 09:14:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 09:14:56 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <vUzMYmZn2xE6ZnFoz_IITXfZ5MbV3kg_ELDnECAIQQo=.c1229f3a-fa3b-46f2-8ca4-06e09cd34a50@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1604:

> 1602:                 if (addr != null) {
> 1603:                     sb.append(" local=");
> 1604:                     sb.append(addr.toString());

I assume you don't need the toString() here, sb.append(addr) will do.

src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 76:

> 74:             t.setDaemon(true);
> 75:             return t;
> 76:         };

This is another case where we should move to InnocuousThread, not this PR of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844942048
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844942162

From alanb at openjdk.org  Sat Nov 16 09:40:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 09:40:46 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
Message-ID: <o4kc8KwhSWzOsyrnRGkVDLd-3Kh3Kv97Hf5V9OVAAtM=.e82c3e30-b00b-4462-a250-169529e1e289@github.com>

On Sat, 16 Nov 2024 00:33:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments

I did another pass over everything, good cleanup, I think only a few issues remaining.

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2440338339

From alanb at openjdk.org  Sat Nov 16 09:40:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 09:40:47 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <t0yQ1Llj6V4e-y_-uwtz0JsLUQqyiQhj1y5bDzJGxmY=.0419db17-40b7-4e22-b589-481ba59091ce@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
 <t0yQ1Llj6V4e-y_-uwtz0JsLUQqyiQhj1y5bDzJGxmY=.0419db17-40b7-4e22-b589-481ba59091ce@github.com>
Message-ID: <SMmZg_ryqiWNhLs2dDUPf4g273u5dQuPjshsKxCaSQk=.e70546e8-3c2b-4723-9d7b-9d1bb7baec26@github.com>

On Sat, 16 Nov 2024 06:13:13 GMT, Glavo <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Address reviewer comments
>
> src/java.base/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java line 48:
> 
>> 46:     // thread pool. Internal threads do not dispatch to completion handlers.
>> 47:     private static final int internalThreadCount =
>> 48:         Integer.valueOf(System.getProperty("sun.nio.ch.internalThreadPoolSize", "1"));
> 
> Suggestion:
> 
>         Integer.getInteger("sun.nio.ch.internalThreadPoolSize", 1);

Yes, the it should use Integer.getInteger here, same thing in Invoker.java.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1844945498

From rriggs at openjdk.org  Mon Nov 18 14:58:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 14:58:09 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <VvC4fSK1bQ0zHD1v2W2Odv3-aAE6DbxwI_h0rh95E1Y=.4fa68137-fe71-4c48-8052-badb1cc502d1@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2442860753

From bpb at openjdk.org  Mon Nov 18 16:32:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 16:32:14 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v4]
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <--fTeZMF89uBDXEHg5hXusXGtYW0OCkkDonZPzmHKCU=.22ab75a6-6d3b-4fb2-a1c4-d119e82e5ee4@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

  8344078: Address reviewer comments since previous commit except about InnoucuousThread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22132/files
  - new: https://git.openjdk.org/jdk/pull/22132/files/c1c348f7..bc563aee

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

  Stats: 14 lines in 7 files changed: 0 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22132/head:pull/22132

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

From alanb at openjdk.org  Mon Nov 18 16:43:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 16:43:57 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v4]
In-Reply-To: <--fTeZMF89uBDXEHg5hXusXGtYW0OCkkDonZPzmHKCU=.22ab75a6-6d3b-4fb2-a1c4-d119e82e5ee4@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <--fTeZMF89uBDXEHg5hXusXGtYW0OCkkDonZPzmHKCU=.22ab75a6-6d3b-4fb2-a1c4-d119e82e5ee4@github.com>
Message-ID: <ZsXhS0UFMSal7fXNEUw7ZhwPzz309PHf8vQdaPrHTJg=.0bff7d56-1e76-465d-b136-3640ad036a30@github.com>

On Mon, 18 Nov 2024 16:32:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Address reviewer comments since previous commit except about InnoucuousThread

Good work, good riddance, good cleanup.

src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 732:

> 730:                     sb.append("unbound");
> 731:                 } else if (isUnixSocket()) {
> 732:                     sb.append(addr.toString());

Here's another case where the toString isn't needed.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2443162053
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1846916300

From bpb at openjdk.org  Mon Nov 18 17:04:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 17:04:09 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

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

  8344078: Remove one straggling toString()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22132/files
  - new: https://git.openjdk.org/jdk/pull/22132/files/bc563aee..7b7f23cf

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

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

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

From bpb at openjdk.org  Mon Nov 18 17:04:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 17:04:10 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v4]
In-Reply-To: <ZsXhS0UFMSal7fXNEUw7ZhwPzz309PHf8vQdaPrHTJg=.0bff7d56-1e76-465d-b136-3640ad036a30@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <--fTeZMF89uBDXEHg5hXusXGtYW0OCkkDonZPzmHKCU=.22ab75a6-6d3b-4fb2-a1c4-d119e82e5ee4@github.com>
 <ZsXhS0UFMSal7fXNEUw7ZhwPzz309PHf8vQdaPrHTJg=.0bff7d56-1e76-465d-b136-3640ad036a30@github.com>
Message-ID: <ib3GxXEcybFpXnPx_jaYaW1gkG7VD8mkx1BfR3yO74s=.3959ae71-42f3-4c23-89ea-9f930233d995@github.com>

On Mon, 18 Nov 2024 16:38:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Address reviewer comments since previous commit except about InnoucuousThread
>
> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 732:
> 
>> 730:                     sb.append("unbound");
>> 731:                 } else if (isUnixSocket()) {
>> 732:                     sb.append(addr.toString());
> 
> Here's another case where the toString isn't needed.

Fixed in 7b7f23c. Prior resolved conversations addressed in bc563ae.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1846948666

From alanb at openjdk.org  Mon Nov 18 17:18:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 17:18:02 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
Message-ID: <OGC1nWz8VXXOkkSnCxyZ8R2IZfBX3Iz7ia3fXRH2vVg=.97503ba4-8602-4238-8930-c590d920cf7e@github.com>

On Mon, 18 Nov 2024 17:04:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Remove one straggling toString()

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2443244685

From naoto at openjdk.org  Mon Nov 18 18:24:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 18:24:55 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <WczcXqXBNNc65alyRCEp03ofhcQnSEEETVKcEZXOvXU=.ee032011-4057-4a21-8337-93dcd703624b@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22162#issuecomment-2483799286

From naoto at openjdk.org  Mon Nov 18 18:24:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 18:24:56 GMT
Subject: Integrated: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <uQ0jSNtYfmGheaGR6ZTjsW2r0Q_UQVAvSsvCKKCDJnA=.7c6957f3-f5c9-4ec8-a806-0185bcac1f10@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

This pull request has now been integrated.

Changeset: c59adf68
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c59adf68d9ac49b41fb778041e3949a8057e8d7f
Stats:     12 lines in 1 file changed: 0 ins; 9 del; 3 mod

8344330: Remove AccessController.doPrivileged() from jdk.charsets module

Reviewed-by: lancea, bpb, rriggs, jlu

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

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

From rriggs at openjdk.org  Mon Nov 18 19:07:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 19:07:51 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
Message-ID: <v3OPS53nphTsvXrG-K6IsvBKOU4cmJChHKK2XAF27cI=.3ad6af8d-d3da-4980-aa2d-e823c88786fc@github.com>

On Mon, 18 Nov 2024 17:04:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Remove one straggling toString()

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22132#pullrequestreview-2443472939

From bpb at openjdk.org  Mon Nov 18 19:19:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 19:19:58 GMT
Subject: Integrated: 8344078: Remove security manager dependency in java.nio
In-Reply-To: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
Message-ID: <tGAs3YkIHeYYX0R6Ta1NQqmIsyEOTkf9HYvrw6qYxoM=.27e17876-1293-451d-b4d7-168cbefe244b@github.com>

On Fri, 15 Nov 2024 05:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.

This pull request has now been integrated.

Changeset: 922b12f3
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/922b12f30c4cfd6b504d66daf37fb30c7fb1bfe7
Stats:     1489 lines in 67 files changed: 9 ins; 1204 del; 276 mod

8344078: Remove security manager dependency in java.nio

Reviewed-by: alanb, rriggs

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

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

From alanb at openjdk.org  Tue Nov 19 07:46:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 07:46:21 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
Message-ID: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>

Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

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

Commit messages:
 - Merge branch 'JDK-8344328'
 - More improvements
 - Initial commit

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

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

From liach at openjdk.org  Tue Nov 19 07:46:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 07:46:21 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
Message-ID: <Mm6cL06SqzjmpyuhNe-VraKnhQ9e2Kbh9M50R8ivKIo=.153b8550-6f75-479d-ac7a-935da2f8dead@github.com>

On Mon, 18 Nov 2024 16:17:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 865:

> 863:                     }
> 864: 
> 865:                     // send the datagram (does not block)

Now this send is in the synchronized block; should this "does not block" be moved to the top level synchronized block?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22212#discussion_r1847343667

From alanb at openjdk.org  Tue Nov 19 07:46:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 07:46:21 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <Mm6cL06SqzjmpyuhNe-VraKnhQ9e2Kbh9M50R8ivKIo=.153b8550-6f75-479d-ac7a-935da2f8dead@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <Mm6cL06SqzjmpyuhNe-VraKnhQ9e2Kbh9M50R8ivKIo=.153b8550-6f75-479d-ac7a-935da2f8dead@github.com>
Message-ID: <F0O0mcIYtc-xMtjF8-Jgqz2ynevVEJ9ZpoRkBrNhyd4=.82469a82-8778-4344-8c46-8651b3139193@github.com>

On Mon, 18 Nov 2024 22:10:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.
>
> src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 865:
> 
>> 863:                     }
>> 864: 
>> 865:                     // send the datagram (does not block)
> 
> Now this send is in the synchronized block; should this "does not block" be moved to the top level synchronized block?

The comment is for the call to send, so it's in the right place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22212#discussion_r1847761632

From jpai at openjdk.org  Tue Nov 19 08:20:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 08:20:44 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
Message-ID: <fQEs3AM7jTiwSf6be1QRK-3KpmNpsGlr5tIB0fVyiKo=.22bbde4b-9944-42d8-bc9b-8ce53ab99c71@github.com>

On Mon, 18 Nov 2024 16:17:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

This looks reasonable to me. I believe the previous decision to reduce the scope of `synchronized` blocks in this code was done for https://bugs.openjdk.org/browse/JDK-8312166.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22212#pullrequestreview-2444679164

From aturbanov at openjdk.org  Tue Nov 19 08:25:52 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Nov 2024 08:25:52 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
Message-ID: <U2nMFjh-cY6MUcFc-ac6Xs_bt66b7vM6SSiHacsPb28=.16d3f436-9294-4eac-9562-01d297d187c7@github.com>

On Mon, 18 Nov 2024 17:04:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.nio` and `sun.nio` package hierarchies.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344078: Remove one straggling toString()

src/java.base/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java line 93:

> 91:                 ServiceLoader.load(AsynchronousChannelProvider.class,
> 92:                                    ClassLoader.getSystemClassLoader());
> 93:             Iterator<AsynchronousChannelProvider> i = sl.iterator();

iterator is now unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1847879204

From alanb at openjdk.org  Tue Nov 19 08:34:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 08:34:44 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <fQEs3AM7jTiwSf6be1QRK-3KpmNpsGlr5tIB0fVyiKo=.22bbde4b-9944-42d8-bc9b-8ce53ab99c71@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <fQEs3AM7jTiwSf6be1QRK-3KpmNpsGlr5tIB0fVyiKo=.22bbde4b-9944-42d8-bc9b-8ce53ab99c71@github.com>
Message-ID: <tAggxh2yCFeX_NwiLKMIx14SuxRZk5_Cse5WYjXxobA=.afafa5c6-cc34-4749-bd9e-bdd15cb25179@github.com>

On Tue, 19 Nov 2024 08:17:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This looks reasonable to me. I believe the previous decision to reduce the scope of `synchronized` blocks in this code was done for https://bugs.openjdk.org/browse/JDK-8312166.

That's right, I should have linked to that change in JDK 22. The removal of the SecurityManager support, and the follow-up work in JDK-8344112, means the changes to hold the lock for the duration of both I/O ops is much simpler now as a lot of complexity and code paths go away.

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2485024118

From dfuchs at openjdk.org  Tue Nov 19 14:24:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Nov 2024 14:24:44 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
Message-ID: <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>

On Mon, 18 Nov 2024 16:17:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

Given that anyone can synchronize on DatagramPacket, would it be better to synchronize on `p` in the DatagramSocketAdaptor, before obtaining the readLock/writeLock, in order to reduce the chances of potentially triggering a deadlock?

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

PR Review: https://git.openjdk.org/jdk/pull/22212#pullrequestreview-2445626033

From alanb at openjdk.org  Tue Nov 19 15:00:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 15:00:44 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>
Message-ID: <BOZe_fh59bRCPpWskycLZXAPR-4paNfTfninwvUmmj4=.bd636efe-321c-4de5-8f11-e252a813a836@github.com>

On Tue, 19 Nov 2024 14:21:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Given that anyone can synchronize on DatagramPacket, would it be better to synchronize on `p` in the DatagramSocketAdaptor, before obtaining the readLock/writeLock, in order to reduce the chances of potentially triggering a deadlock?

DatagramPacket isn't specified to be tread safe but as with many JDK 1.0 era APIs, all methods are synchronized. I think your question is about lock ordering as I/O operations require a read or write lock. This isn't specified anywhere but the implementation works consistently to avoid deadlock when using the APIs. If something synchronizes on a DatagramPacket then it would delay, maybe indefinitely, a send or receive op. So I think your concern is whether it might  delay, maybe indefinitely, other send or receive operations with other datagram packages, right? I don't mind changing it. Arguably this would give us closer to what was there before JEP 373 although the legacy implementation didn't correctly coordinate concurrently usage beyond that.

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2485951082

From alanb at openjdk.org  Tue Nov 19 16:08:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 16:08:32 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
Message-ID: <OJ8Pm25daGM1Yi7qFK67j9tEfzi1QcKWBSNEGUlaY-U=.de5013af-2d72-4274-ae77-5f8245a25a0f@github.com>

> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

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

 - Broadly scope of synchronized blocks
 - Merge branch 'master' into JDK-8344328
 - Merge branch 'master' into JDK-8344328
 - Merge branch 'JDK-8344328'
 - More improvements
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22212/files
  - new: https://git.openjdk.org/jdk/pull/22212/files/a50fdddc..ade7ba0b

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

  Stats: 5530 lines in 231 files changed: 573 ins; 3896 del; 1061 mod
  Patch: https://git.openjdk.org/jdk/pull/22212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22212/head:pull/22212

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

From bpb at openjdk.org  Tue Nov 19 21:39:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 21:39:26 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link
Message-ID: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>

Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

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

Commit messages:
 - 8343823: (fs) Files.createLink: inconsistent behavior when creating link to symbolic link

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

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

From bpb at openjdk.org  Tue Nov 19 21:39:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 21:39:26 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link
In-Reply-To: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
Message-ID: <CeQZRtrrIbDV0AIl0FczyY5SqG_RUqLhlx0o4GaxnKI=.26d787ff-e317-43c8-8968-b250d4ab3136@github.com>

On Tue, 19 Nov 2024 21:33:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

The behavior cannot be made specifiable without a backward incompatible change. A similar method with specifiable behavior could be added, for example:

`File.createHardLink(Path link, Path existing, LinkOption... options)`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22257#issuecomment-2486799191

From bpb at openjdk.org  Wed Nov 20 02:24:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 02:24:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v9]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <81nytC3uzQYaDXb49LwlrL-KD-DpQNPpNvT-1ZuEsP4=.bb85996e-8342-4646-9ae3-9796368bc9ea@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=08
  Stats: 1550 lines in 93 files changed: 774 ins; 668 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Wed Nov 20 02:24:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 02:24:15 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: <5l_XeflDxQIpBKlCLN0S0PbcpC3lnP4KHNMkPwbcj4U=.72734adb-4db6-41fd-a241-f792f67728b9@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

The merge commit 403602f built and passed `jdk_core` tests on Linux, macOS, and Windows.

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

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

From jlu at openjdk.org  Wed Nov 20 03:07:28 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:07:28 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
Message-ID: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>

Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 

This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).

After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

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

Commit messages:
 - init

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

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

From lbourges at openjdk.org  Wed Nov 20 06:07:15 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 20 Nov 2024 06:07:15 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <sKK36C_3uK71m8PPYisvl9-SWAvr-_TY8RJtRbFEark=.86fc6127-ce47-4359-92d4-a795e53fe609@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

LGTM

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

Marked as reviewed by lbourges (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2447514188

From alanb at openjdk.org  Wed Nov 20 06:42:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 06:42:14 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link
In-Reply-To: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
Message-ID: <-soRVax5HilZbTmiH8iNdcH5X_yzCqHSiO_mDQ4DAUI=.5722f6e2-e225-443d-b6b7-4188a79d7c70@github.com>

On Tue, 19 Nov 2024 21:33:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

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

> 995:      * whether the new link is for the target of the symbolic link or for the
> 996:      * symbolic link itself is platform dependent and therefore not specified.
> 997:      *

I think is has to be part of the method description rather than an apiNote.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22257#discussion_r1849635549

From alanb at openjdk.org  Wed Nov 20 07:00:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 07:00:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <f-3Cf4AhtV60tWd3TCBpsh1XJzIL5_tUAlazi-MJ92U=.721546e9-49e0-40e2-8b4c-bc8aa398af33@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Some of these were checking if ExceptionOccurred(env) returns NULL so were readable, moving them to ExceptionCheck is fine, and a bit more efficient when there is a pending exception.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2447595468

From lbourges at openjdk.org  Wed Nov 20 07:23:14 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 20 Nov 2024 07:23:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

I will check today if any 'bad' pattern is remaining in the openjdk master source folder... to be sure.

Maybe improving jni documentation would be great in another issue...

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

PR Comment: https://git.openjdk.org/jdk/pull/22266#issuecomment-2487698104

From duke at openjdk.org  Wed Nov 20 14:04:54 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 14:04:54 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

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

 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider
 - Revert "8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider"
   
   This reverts commit 318888339bdc2ee6a632e4850a980d91bff79e79.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21997/files
  - new: https://git.openjdk.org/jdk/pull/21997/files/31888833..10bae79b

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

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

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

From duke at openjdk.org  Wed Nov 20 14:04:54 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 14:04:54 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
 <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
 <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>
Message-ID: <umw-vgVH7uBETehbuarTcmSP6tI_ZYzi9ejh2Pg-h5w=.3df81e01-3121-42e0-a10c-5fcab2323ccf@github.com>

On Sun, 10 Nov 2024 17:04:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.
>> 
>> In ImageReaderFactory:
>> 
>> private static final Path BOOT_MODULES_JIMAGE = null;
>> 
>>     static {
>>         // check installed providers
>>         for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
>>             if ("file".equalsIgnoreCase(provider.getScheme())) {
>>                 try {
>>                     BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
>>                     if (BOOT_MODULES_JIMAGE != null) break;
>>                 } catch (UnsupportedOperationException uoe) {
>>                 }
>>             }
>>         }
>>     }
>> 
>> What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!
>
> I assume this will lead to recursive initialisation, e.g. `FileSystems.getFileSystem(URI.create("jrt:/"))` will use FileSystemProvider.installedProviders to iterate over the installed providers.
> 
> I don't have time to look into this more but I think it will have to reflectively get the FileSystem so that the code isn't compiled with references to the built-in provider, as in something like this (not tested):
> 
> 
>     private static final Path BOOT_MODULES_JIMAGE;
>     static {
>         FileSystem fs;
>         if (ImageReaderFactory.class.getClassLoader() == null) {
>             // fs = DefaultFileSystemProvider.theFileSystem()
>             try {
>                 fs = (FileSystem) Class.forName("sun.nio.fs.DefaultFileSystemProvider")
>                         .getMethod("theFileSystem")
>                         .invoke(null);
>             } catch (Exception e) {
>                 throw new ExceptionInInitializerError(e);
>             }
>         } else {
>             fs = FileSystems.getDefault();
>         }
>         BOOT_MODULES_JIMAGE = fs.getPath(JAVA_HOME, "lib", "modules");
>     }
> 
> Also just to say that we need to create a good test for this issue. I expect it will be rarely to interpose on the default file system and use jrtfs at the same time, but that is what this bug report is about so we'll need to create a good test.

#### The reason why it is difficult to solve the issue through modifying ImageReadFactory directly

1. We only can use the `java8 `api
2. We can not access any classes which are not exported by `java.base` module,even by using java reflection.Because when there is a remote/target jdk, the class in jrt-fs.jar loaded by `JrtFsLoader`  is actually in `Unnamed Module`.

The essence of this issue is that when loading the Main class, which depends on Path.of, then it needs to load CustomFileSystemProvider, resulting in a circular dependency, which will access the fields of a class that is still being initialized.

The correct situation should be that Main class should be loaded with CustomFileSystemProvided, and when it comes to CustomFileSystemProvided it should use Built-in FileSystemProvider.

But if we following the above assumptions, and when we **first load the main class**, we will run to the `SystemModuleFinders# findImageLocation`  twice then the `ImageReader imageReader = SystemImage.reader()` will be null because we should load the customFileSystemProvider during main class loading and the the both of loading will use the same  `SystemModuleFinders# findImageLocation` method.So we must load the CustomFileSystemProvided **before** loading main class.

#### The solution

1. In `System#initPhase3` which will be called before loading main class, load the CustomFileSystemProvided after `VM.initLevel(4);`.Because we will use **SystemClassLoader**.
2. And we need also to ensure the return value of `FileSystems#getDefault` is `DefaultFileSystemProvider.theFileSystem`, which depends on the value of `VM.isModuleSystemInited()`. But now the `VM.initLevel` is **4** so the value of `VM.isModuleSystemInited()` is **false**. At first I want to change the judgment condition of `if` . That means I need to create a initLevel after `SYSTEM_BOOTED = 4`, but there is already `SYSTEM_SHUTDOWN = 5` defined in VM class.I can not set a `4.5` value to a new initLevel,so I add a new  boolen field to represent the status of loading CustomFileSystemProvider.Its initValue is **false** and its value can only be set from false to true so there is no need for lock.
3. Change the judgment condition of `if` to `if (VM.isModuleSystemInited()&&VM.isCustomDefaultFileSystemProviderLoaded())`
4. After load the CustomFileSystemProvided,  regardless of whether the  `-Djava.nio.file.spi.DefaultFileSystemProvider`  was set, it needs to call `VM.setCustomDefaultFileSystemProviderLoaded();`

After loading the CustomFileSystemProvided, the initialization of `Path BOOT_MODULES_JIMAGE = ImageReaderFactory#Paths.get(JAVA_HOME, "lib", "modules");` will use the fileSystem which is provided by the loaded CustomFileSystemProvided. Even it will also call `FileSystems#getDefaultProvider` , but during where it actually only use the constructor to new instance because relevent classes were already loaded.

For detail modification see the latest commit.

I recompile the modified source and test the situation mentioned in the issue(actually the issue is submitted by me through oracle bug submission because I am not openjdk author) and the normal situation, it successed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1850371330

From alanb at openjdk.org  Wed Nov 20 14:14:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 14:14:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
Message-ID: <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>

On Wed, 20 Nov 2024 14:04:54 GMT, jyxzwd <duke at openjdk.org> wrote:

>> Use the built-in file system provider rather than the custom file system provider.
>> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.
>
> jyxzwd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider
>  - Revert "8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider"
>    
>    This reverts commit 318888339bdc2ee6a632e4850a980d91bff79e79.

I don't think we should be doing this. Did you try the direction of checking the defining class loader that I outlined in the previous comment?

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2488690052

From dfuchs at openjdk.org  Wed Nov 20 16:03:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 16:03:16 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <BOZe_fh59bRCPpWskycLZXAPR-4paNfTfninwvUmmj4=.bd636efe-321c-4de5-8f11-e252a813a836@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>
 <BOZe_fh59bRCPpWskycLZXAPR-4paNfTfninwvUmmj4=.bd636efe-321c-4de5-8f11-e252a813a836@github.com>
Message-ID: <JTNdX_tT0Pj1ZK_2s5EExtCzTYExd7XZimoWYLi8l54=.c72987c3-ab7b-4e11-a2be-f37d714f026c@github.com>

On Tue, 19 Nov 2024 14:58:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> DatagramPacket isn't specified to be tread safe but as with many JDK 1.0 era APIs, all methods are synchronized. I think your question is about lock ordering as I/O operations require a read or write lock. This isn't specified anywhere but the implementation works consistently to avoid deadlock when using the APIs. If something synchronizes on a DatagramPacket then it would delay, maybe indefinitely, a send or receive op. So I think your concern is whether it might delay, maybe indefinitely, other send or receive operations with other datagram packages, right? I don't mind changing it. Arguably this would give us closer to what was there before JEP 373 although the legacy implementation didn't correctly coordinate concurrently usage beyond that.

Correct - my concern is with lock ordering, and existing custom code that might have been written before JEP 373, and that might synchronize on DatagramPacket. I'm OK if you think it's better to keep all the synchro in DatagramChannelImpl, but since the methods that take a DatagramPacket are only called from the DatagramSocketAdaptor I was wondering if it would be more pertinent to synchronize on DatagramPacket from there (and bring it closer to pre JEP 373 implementation).

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2488972803

From bpb at openjdk.org  Wed Nov 20 16:12:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 16:12:06 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v2]
In-Reply-To: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
Message-ID: <_W1IH5mdBRoHF9U-tGnDFwLhP7ZvJxF98dh8LEfvYDc=.6632ac9e-7e9a-4544-a29c-042aa748ff2d@github.com>

> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

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

  8343823: Move API note verbiage into the method description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22257/files
  - new: https://git.openjdk.org/jdk/pull/22257/files/43184d4e..10b46991

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

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

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

From bpb at openjdk.org  Wed Nov 20 16:12:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 16:12:08 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v2]
In-Reply-To: <-soRVax5HilZbTmiH8iNdcH5X_yzCqHSiO_mDQ4DAUI=.5722f6e2-e225-443d-b6b7-4188a79d7c70@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
 <-soRVax5HilZbTmiH8iNdcH5X_yzCqHSiO_mDQ4DAUI=.5722f6e2-e225-443d-b6b7-4188a79d7c70@github.com>
Message-ID: <5yKtgHcTBeBY0W4adhj8ywpEyNVh60pHIjz4kwfSBUQ=.5614b8e4-8192-420b-b276-36b13118ffc2@github.com>

On Wed, 20 Nov 2024 06:39:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343823: Move API note verbiage into the method description
>
> src/java.base/share/classes/java/nio/file/Files.java line 997:
> 
>> 995:      * whether the new link is for the target of the symbolic link or for the
>> 996:      * symbolic link itself is platform dependent and therefore not specified.
>> 997:      *
> 
> I think is has to be part of the method description rather than an apiNote.

Done in commit 10b4699.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22257#discussion_r1850600147

From duke at openjdk.org  Wed Nov 20 17:30:17 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 17:30:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
Message-ID: <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>

On Wed, 20 Nov 2024 14:11:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think we should be doing this. Did you try the direction of checking the defining class loader that I outlined in the previous comment?

yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489173647

From alanb at openjdk.org  Wed Nov 20 17:33:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 17:33:20 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <JTNdX_tT0Pj1ZK_2s5EExtCzTYExd7XZimoWYLi8l54=.c72987c3-ab7b-4e11-a2be-f37d714f026c@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>
 <BOZe_fh59bRCPpWskycLZXAPR-4paNfTfninwvUmmj4=.bd636efe-321c-4de5-8f11-e252a813a836@github.com>
 <JTNdX_tT0Pj1ZK_2s5EExtCzTYExd7XZimoWYLi8l54=.c72987c3-ab7b-4e11-a2be-f37d714f026c@github.com>
Message-ID: <Y6NHbxpMiNMZyTn7c4mnWdMXLBPQTLHqs3EdBASqUak=.6d20b463-48da-454b-b674-25bdada5f0f9@github.com>

On Wed, 20 Nov 2024 16:00:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Correct - my concern is with lock ordering, and existing custom code that might have been written before JEP 373, and that might synchronize on DatagramPacket. I'm OK if you think it's better to keep all the synchro in DatagramChannelImpl, but since the methods that take a DatagramPacket are only called from the DatagramSocketAdaptor I was wondering if it would be more pertinent to synchronize on DatagramPacket from there (and bring it closer to pre JEP 373 implementation).

The read/write lock used by DatagramChannel is not exposed so the ordering is hard to observe. In any case, I think what we have in the PR aligns with the locking that has been there since JDK 1.0. That is, it does in synchronized (p) in DatagramSocketAdaptor.send/receive It's a bit icky as the blockingXXX methods needs to assert that the current thread holds the lock, and doing in blockingXXX would work the same (the difference is not observable).

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2489181007

From alanb at openjdk.org  Wed Nov 20 17:37:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 17:37:20 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v2]
In-Reply-To: <_W1IH5mdBRoHF9U-tGnDFwLhP7ZvJxF98dh8LEfvYDc=.6632ac9e-7e9a-4544-a29c-042aa748ff2d@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
 <_W1IH5mdBRoHF9U-tGnDFwLhP7ZvJxF98dh8LEfvYDc=.6632ac9e-7e9a-4544-a29c-042aa748ff2d@github.com>
Message-ID: <swTdqQ33T4ZQnzKwPhTT3tMYs1m-NCb5V06fFAPJ7Tg=.a22ea7a7-b67a-43b5-a1aa-cee0b8e1cadc@github.com>

On Wed, 20 Nov 2024 16:12:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343823: Move API note verbiage into the method description

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

> 985:      * known as creating a "hard link". Whether the file attributes are
> 986:      * maintained for the file or for each directory entry is file system
> 987:      * specific and therefore not specified. If the {@code existing} parameter

Thanks for moving the method description. Can you try putting the new sentence before the "Typically, a file system" sentence as I think will flow a bit better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22257#discussion_r1850733371

From jlu at openjdk.org  Wed Nov 20 17:57:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 17:57:19 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
 <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>
Message-ID: <_uiPNkjyjyYAV1ctBsY64m1j07SEmypyIpxKpe_Uyx4=.7f96d8fc-b45b-4324-9ac2-ff5056d15d3a@github.com>

On Wed, 20 Nov 2024 07:20:32 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> I will check today if any 'bad' pattern is remaining in the openjdk master source folder... to be sure.
> 
> Maybe improving jni documentation would be great in another issue...

Thanks for checking @bourgesl. The JNI docs did in fact get an update as well in [JDK-8341799](https://bugs.openjdk.org/browse/JDK-8341799).

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

PR Comment: https://git.openjdk.org/jdk/pull/22266#issuecomment-2489223014

From alanb at openjdk.org  Wed Nov 20 18:05:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 18:05:22 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
Message-ID: <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>

On Wed, 20 Nov 2024 17:27:18 GMT, jyxzwd <duke at openjdk.org> wrote:

> yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?

If a tool is using jrtfs to get at the classes/resources in another run-time image then you'll have two versions of the jrt FileSystemProvider and the support jimage support in use. For the local case (current runtime), the classes comes from java.base and be defined to the boot module. For the remote case, the classes will be loaded from the remote jrt-fs.jar and defined to custom class loader (see JrtFsLoader in JrtFileSystemProvider).

It gets complicated once you replace the default file system provider. The change means the "local" provider and image reader won't go through the custom file system provider. The "remote" provider and image reader will have their I/O intercepted by the custom file system provider.

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489237978

From naoto at openjdk.org  Wed Nov 20 18:06:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 18:06:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <fmMbpUFvBu7fVxIm6c2TuXsEwzg0Ckl6ux5W_SAJsGg=.33ea7435-8048-4d6c-a4fa-aecef0f90c4a@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2449357730

From bpb at openjdk.org  Wed Nov 20 18:07:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 18:07:35 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v3]
In-Reply-To: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
Message-ID: <U4U3xT1iJycLW3B_TyZWBGdq7PMxpzWfEE0uxM4pdog=.b97010ad-6b9a-468b-9ecb-d3f62bb14e7d@github.com>

> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

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

  8343823: Move new sentence to before "Whether..."

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22257/files
  - new: https://git.openjdk.org/jdk/pull/22257/files/10b46991..3db1cfb5

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

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

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

From alanb at openjdk.org  Wed Nov 20 18:07:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 18:07:35 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v3]
In-Reply-To: <U4U3xT1iJycLW3B_TyZWBGdq7PMxpzWfEE0uxM4pdog=.b97010ad-6b9a-468b-9ecb-d3f62bb14e7d@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
 <U4U3xT1iJycLW3B_TyZWBGdq7PMxpzWfEE0uxM4pdog=.b97010ad-6b9a-468b-9ecb-d3f62bb14e7d@github.com>
Message-ID: <OUXdwN5AEkD6OzFcFU6gMYFZcqVhELyt-RFSuHeOI74=.64976cb2-30dc-4b05-9280-d0813f98b43c@github.com>

On Wed, 20 Nov 2024 18:04:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343823: Move new sentence to before "Whether..."

Thanks for the update, I think it reads well know. I think we'll need to create a CSR for this.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22257#pullrequestreview-2449359458

From bpb at openjdk.org  Wed Nov 20 18:07:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 18:07:36 GMT
Subject: RFR: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link [v2]
In-Reply-To: <swTdqQ33T4ZQnzKwPhTT3tMYs1m-NCb5V06fFAPJ7Tg=.a22ea7a7-b67a-43b5-a1aa-cee0b8e1cadc@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
 <_W1IH5mdBRoHF9U-tGnDFwLhP7ZvJxF98dh8LEfvYDc=.6632ac9e-7e9a-4544-a29c-042aa748ff2d@github.com>
 <swTdqQ33T4ZQnzKwPhTT3tMYs1m-NCb5V06fFAPJ7Tg=.a22ea7a7-b67a-43b5-a1aa-cee0b8e1cadc@github.com>
Message-ID: <JCmC6ZZYOXaIH3NWA4RG8ryH1VAo5_jscDY5jmhILF0=.5cd056fb-c7d9-4df7-99e9-25500fd73952@github.com>

On Wed, 20 Nov 2024 17:34:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343823: Move API note verbiage into the method description
>
> src/java.base/share/classes/java/nio/file/Files.java line 987:
> 
>> 985:      * known as creating a "hard link". Whether the file attributes are
>> 986:      * maintained for the file or for each directory entry is file system
>> 987:      * specific and therefore not specified. If the {@code existing} parameter
> 
> Thanks for moving the method description. Can you try putting the new sentence before the "Whether the file attributes ..." sentence as I think will flow a bit better.

Moved in commit 3db1cfb.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22257#discussion_r1850767439

From duke at openjdk.org  Wed Nov 20 18:33:27 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 18:33:27 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
Message-ID: <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>

On Wed, 20 Nov 2024 18:02:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?
> 
> If a tool is using jrtfs to get at the classes/resources in another run-time image then you'll have two versions of the jrt FileSystemProvider and the support jimage support in use. For the local case (current runtime), the classes comes from java.base and be defined to the boot module. For the remote case, the classes will be loaded from the remote jrt-fs.jar and defined to custom class loader (see JrtFsLoader in JrtFileSystemProvider).
> 
> It gets complicated once you replace the default file system provider. The change means the "local" provider and image reader won't go through the custom file system provider. The "remote" provider and image reader will have their I/O intercepted by the custom file system provider.

I see, thank you for your detailed explanation! Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489269311

From iris at openjdk.org  Wed Nov 20 18:57:13 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 20 Nov 2024 18:57:13 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <cp2GBR7hb6E-Va1wEaSuUlSZWaznWNA-u-y9vglMG4c=.975f8c0b-4328-45a0-9e1f-f4de64f6d5d0@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2449454066

From bpb at openjdk.org  Wed Nov 20 23:12:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 23:12:43 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
Message-ID: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>

Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

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

Commit messages:
 - 8344659: Some uses of GetPropertyAction were not removed from java.io and java.nio

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

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

From lancea at openjdk.org  Wed Nov 20 23:17:13 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 20 Nov 2024 23:17:13 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

LGTM

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2449890758

From naoto at openjdk.org  Wed Nov 20 23:37:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 23:37:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

Changes in `java.io.Console` and `sun.nio.cs.GB18030` look good.

src/java.base/share/classes/sun/nio/fs/Util.java line 40:

> 38: 
> 39:     private static final Charset jnuEncoding = Charset.forName(
> 40:         System.getProperty("sun.jnu.encoding"));

`StaticProperty.jnuEncoding()` can be used

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

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2449920128
PR Review Comment: https://git.openjdk.org/jdk/pull/22285#discussion_r1851119973

From bpb at openjdk.org  Thu Nov 21 01:22:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:22:20 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>
Message-ID: <Mvi9FGKhkFnDSb_YS1asaEdf2lZ9DFs3MQu__2azenU=.12a84872-d47c-4f6a-b060-9a32ea082376@github.com>

On Wed, 20 Nov 2024 23:14:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> LGTM

@LanceAndersen , @naotoj Thanks for the reviews. I'll fiix Util.java and hold off integrating until tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/22285#issuecomment-2489870120

From bpb at openjdk.org  Thu Nov 21 01:45:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:45:56 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

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

  8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22285/files
  - new: https://git.openjdk.org/jdk/pull/22285/files/cbd5232b..791663e3

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

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

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

From bpb at openjdk.org  Thu Nov 21 01:45:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:45:56 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>
Message-ID: <4TyPpNOMTozlNQWOJJgEjN3lXot4z50TkcAtFcCf-DI=.1334e598-e844-460b-b375-ae9d732cced4@github.com>

On Wed, 20 Nov 2024 23:34:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()
>
> src/java.base/share/classes/sun/nio/fs/Util.java line 40:
> 
>> 38: 
>> 39:     private static final Charset jnuEncoding = Charset.forName(
>> 40:         System.getProperty("sun.jnu.encoding"));
> 
> `StaticProperty.jnuEncoding()` can be used

Fixed in commit 791663e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22285#discussion_r1851201235

From rriggs at openjdk.org  Thu Nov 21 03:04:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 03:04:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <KyPlVx9JH3V0jTJotK1VB555adIiFYHtzzwNKW8-pIs=.f53af89c-6fe1-4366-8ac6-d352ab2e070d@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2450121759

From iris at openjdk.org  Thu Nov 21 04:29:16 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 21 Nov 2024 04:29:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <Pk4loyifwdPDW98BXGdaGmb0e0h6La5JAAhnuwMIcBY=.3b4be0de-334a-41ab-a427-b6f0a496a5d6@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2450202981

From lancea at openjdk.org  Thu Nov 21 11:44:22 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 21 Nov 2024 11:44:22 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <_XR76BkIfBM5JPHDyC8Y23nuAQgGXJAXceT5opavZ_c=.ab19fa43-cb53-40d6-a392-f76dd701efad@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451120906

From alanb at openjdk.org  Thu Nov 21 14:11:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 14:11:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
 <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
Message-ID: <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>

On Wed, 20 Nov 2024 18:20:35 GMT, jyxzwd <duke at openjdk.org> wrote:

> Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?

I think it would be good to add a test and add it to this PR with the updated patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2491304990

From duke at openjdk.org  Thu Nov 21 14:23:27 2024
From: duke at openjdk.org (jyxzwd)
Date: Thu, 21 Nov 2024 14:23:27 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
 <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
 <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>
Message-ID: <jLjkZsfD1mwqmm-ZBmAiV3qIYradwy487DEhOUs0uPE=.956370a5-dada-44ff-942b-68ca8dc3f8af@github.com>

On Thu, 21 Nov 2024 14:08:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?
> 
> I think it would be good to add a test and add it to this PR with the updated patch.

ok,I will do this later.Thank you for your guidance.

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

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2491343078

From dfuchs at openjdk.org  Thu Nov 21 15:10:19 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 15:10:19 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <Y6NHbxpMiNMZyTn7c4mnWdMXLBPQTLHqs3EdBASqUak=.6d20b463-48da-454b-b674-25bdada5f0f9@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <P1EUF8nSK-Dzv9ryraPqLjQ-KJEIek0NEQVCjoT_wso=.70187e0b-7517-4c45-bc41-1731038da9b8@github.com>
 <BOZe_fh59bRCPpWskycLZXAPR-4paNfTfninwvUmmj4=.bd636efe-321c-4de5-8f11-e252a813a836@github.com>
 <JTNdX_tT0Pj1ZK_2s5EExtCzTYExd7XZimoWYLi8l54=.c72987c3-ab7b-4e11-a2be-f37d714f026c@github.com>
 <Y6NHbxpMiNMZyTn7c4mnWdMXLBPQTLHqs3EdBASqUak=.6d20b463-48da-454b-b674-25bdada5f0f9@github.com>
Message-ID: <QqWfxlj1jdokPE3vrcuqvKZraHf7LG9gOmRv-L4YxmM=.17de3975-2bc0-4692-a97e-3e2deb6b45ff@github.com>

On Wed, 20 Nov 2024 17:31:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The read/write lock used by DatagramChannel is not exposed so the ordering is hard to observe. In any case, I think what we have in the PR aligns with the locking that has been there since JDK 1.0. That is, it does in synchronized (p) in DatagramSocketAdaptor.send/receive It's a bit icky as the blockingXXX methods needs to assert that the current thread holds the lock, and doing in blockingXXX would work the same (the difference is not observable).

I see. I'm OK with both solutions - so choose the one you like more and I will (re-)approve if needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2491485296

From dfuchs at openjdk.org  Thu Nov 21 15:10:19 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 15:10:19 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <OJ8Pm25daGM1Yi7qFK67j9tEfzi1QcKWBSNEGUlaY-U=.de5013af-2d72-4274-ae77-5f8245a25a0f@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <OJ8Pm25daGM1Yi7qFK67j9tEfzi1QcKWBSNEGUlaY-U=.de5013af-2d72-4274-ae77-5f8245a25a0f@github.com>
Message-ID: <RwVAxeZxDNkGSKnDA2Dmb2T4qWHzKU76UAfKEuN4k-c=.b3d6904d-a630-4176-acf1-f871ae8af7ed@github.com>

On Tue, 19 Nov 2024 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Broadly scope of synchronized blocks
>  - Merge branch 'master' into JDK-8344328
>  - Merge branch 'master' into JDK-8344328
>  - Merge branch 'JDK-8344328'
>  - More improvements
>  - Initial commit

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22212#pullrequestreview-2451783392

From dfuchs at openjdk.org  Thu Nov 21 15:18:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 15:18:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <We3p12lva2kkGDg1yrVFjgNTRnB3mR5XI9rbMM4VTv0=.262b6473-bfaa-4f32-b720-94c1e0f56b0f@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Looks good.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451805562

From duke at openjdk.org  Thu Nov 21 15:27:23 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Thu, 21 Nov 2024 15:27:23 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <wGHKfu2oWdzPQbGwTiuCNYADYhxCw7nPBNuxecHiPxs=.e345b4d4-abda-42f0-a98f-79b1981e4194@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451829858

From bpb at openjdk.org  Thu Nov 21 16:20:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 16:20:24 GMT
Subject: Integrated: 8343823: (fs) Files.createLink: inconsistent behavior when
 creating link to symbolic link
In-Reply-To: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
References: <NsEHhsjzbVifruLkMjc03fP8WkRMMW3kLj4wkouTmz8=.c2525be9-7cb1-4c72-a3de-b14bf9ab8449@github.com>
Message-ID: <fuQTDdvplXt0QBsi11M-ZMUDx_VWLaMNA0kR4-WRnow=.284e26c4-f81b-4f0f-8171-b005f1e3d833@github.com>

On Tue, 19 Nov 2024 21:33:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an API note to `java.nio.file.Files.createLink` to make explicit that the behavior when the target is a symbolic link is unspecified.

This pull request has now been integrated.

Changeset: aaf3df7b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aaf3df7bb80d84d3870d8840c2935d4567f83f3c
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8343823: (fs) Files.createLink: inconsistent behavior when creating link to symbolic link

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Nov 21 16:21:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 16:21:22 GMT
Subject: Integrated: 8344659: Some uses of GetPropertyAction were not removed
 from java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <xQpgV01vjtcG-eeXEUP7dRRMxRkMXY9dQ0BHz3Z-72I=.6d7798b8-a359-43b4-8bce-09032955cf93@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

This pull request has now been integrated.

Changeset: 87be63f8
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87be63f85dbbfd8695817a913ef2b2ae5b0d78e9
Stats:     25 lines in 9 files changed: 0 ins; 8 del; 17 mod

8344659: Some uses of GetPropertyAction were not removed from java.io and java.nio

Reviewed-by: lancea, rriggs, iris, dfuchs

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

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

From alanb at openjdk.org  Thu Nov 21 16:28:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 16:28:22 GMT
Subject: RFR: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet [v2]
In-Reply-To: <OJ8Pm25daGM1Yi7qFK67j9tEfzi1QcKWBSNEGUlaY-U=.de5013af-2d72-4274-ae77-5f8245a25a0f@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
 <OJ8Pm25daGM1Yi7qFK67j9tEfzi1QcKWBSNEGUlaY-U=.de5013af-2d72-4274-ae77-5f8245a25a0f@github.com>
Message-ID: <oB2Vj_HWXSVLRiYtcGbehfjlB1o5M6_o_hlrt8airXE=.a08b6d20-506d-4b82-8a5c-1b6701794e17@github.com>

On Tue, 19 Nov 2024 16:08:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Broadly scope of synchronized blocks
>  - Merge branch 'master' into JDK-8344328
>  - Merge branch 'master' into JDK-8344328
>  - Merge branch 'JDK-8344328'
>  - More improvements
>  - Initial commit

Thanks, let's go with what we have.

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

PR Comment: https://git.openjdk.org/jdk/pull/22212#issuecomment-2491699389

From alanb at openjdk.org  Thu Nov 21 16:28:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 16:28:22 GMT
Subject: Integrated: 8344328: (dc) DatagramChannelImpl.blockingReceive can now
 synchronize on packet
In-Reply-To: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
References: <tN3sEyBbHO2HzuWMIa20HWf7PO5x2GYLqOYyCEUlcTs=.fc2cc691-5e71-4a17-9dfe-0e90a537c283@github.com>
Message-ID: <4Jz40A4AQE9u5INtJmw-w2D4U3YDwK1N5PE7iK4l0Kw=.7e52f65c-b1a4-404d-938c-ce702aa95283@github.com>

On Mon, 18 Nov 2024 16:17:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that JEP 491 is integrated, we can restore long-standing behavior in the DatagramSocket adaptor to synchronize on the DatagramPacket for the duration of the send/receive.

This pull request has now been integrated.

Changeset: dfa18fe6
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfa18fe6b395171c821cde02f081e12dd1565ba5
Stats:     66 lines in 2 files changed: 22 ins; 29 del; 15 mod

8344328: (dc) DatagramChannelImpl.blockingReceive can now synchronize on packet

Reviewed-by: dfuchs, jpai

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

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

From jlu at openjdk.org  Fri Nov 22 18:21:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Nov 2024 18:21:21 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <wwcruvoYGBhHJ4yGWyBmDa78ea4NVyxgooPjXABucsg=.ee86945e-1c03-493a-81ad-e059c6d35a83@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22266#issuecomment-2494478441

From jlu at openjdk.org  Fri Nov 22 18:21:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Nov 2024 18:21:22 GMT
Subject: Integrated: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <6hGAqTivmss61-sfbuQvW8WKS9kCLzwizArk8XJLXtw=.736f839a-b399-463a-8d5f-e5e8608c9709@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

This pull request has now been integrated.

Changeset: 51763b67
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51763b67004a8b37d9bf4b8efef8aa1fa7bc9f4a
Stats:     16 lines in 6 files changed: 0 ins; 0 del; 16 mod

8344525: Fix leftover ExceptionOccurred in java.base

Reviewed-by: lbourges, alanb, naoto, iris

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

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

From tprinzing at openjdk.org  Fri Nov 22 20:32:50 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Fri, 22 Nov 2024 20:32:50 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>

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

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

  Added more tests for socket connect events.
  
  - SocketAdapter connect
  - SocketAdapter connect with exception
  - Socket connect with exception
  - SocketChannel connect with exception
  - SocketChannel non-blocking connect
  - SocketChannel non-blocking connect with exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/ce9d39e2..13f81570

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

  Stats: 177 lines in 5 files changed: 162 ins; 0 del; 15 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 bpb at openjdk.org  Fri Nov 22 23:48:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Nov 2024 23:48:24 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count against
 the upper limit on direct buffer memory
Message-ID: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>

Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

Commit messages:
 - 8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

Changes: https://git.openjdk.org/jdk/pull/22339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344882
  Stats: 43 lines in 5 files changed: 28 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22339/head:pull/22339

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

From bpb at openjdk.org  Fri Nov 22 23:48:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 22 Nov 2024 23:48:24 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <PM7uvtzUF-z72DgN6OXfK2M2X_OotI27Fbi408ggfLQ=.d095f30a-95ed-40fb-af23-5a018495e6e3@github.com>

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

This change should also fix [JDK-8340728](https://bugs.openjdk.org/browse/JDK-8340728) and [JDK-8342849](https://bugs.openjdk.org/browse/JDK-8342849) as a side effect.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2495106861

From duke at openjdk.org  Sat Nov 23 01:07:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 23 Nov 2024 01:07:14 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <-mnoOq9jXyXXL2rVP8xI_fsQb4xNHRi4qnNQcGvXEAs=.98bdcb74-c20b-44b2-a69e-1c3fc217caf3@github.com>

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:

> 75:     static final boolean UNALIGNED = Bits.unaligned();
> 76: 
> 77:     private @Stable boolean temporary; // defaults to false

Any?reason this?is?`@Stable` instead?of?`final`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1854957024

From bpb at openjdk.org  Sat Nov 23 01:12:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 23 Nov 2024 01:12:27 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <-mnoOq9jXyXXL2rVP8xI_fsQb4xNHRi4qnNQcGvXEAs=.98bdcb74-c20b-44b2-a69e-1c3fc217caf3@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <-mnoOq9jXyXXL2rVP8xI_fsQb4xNHRi4qnNQcGvXEAs=.98bdcb74-c20b-44b2-a69e-1c3fc217caf3@github.com>
Message-ID: <F9VyaHKG4eUhxXIPmzFG5dGx9o-pKzB1UqlLwpiT91I=.f2d6d5fa-f414-47d6-85b5-222adcad43ef@github.com>

On Sat, 23 Nov 2024 01:03:25 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:
> 
>> 75:     static final boolean UNALIGNED = Bits.unaligned();
>> 76: 
>> 77:     private @Stable boolean temporary; // defaults to false
> 
> Any?reason this?is?`@Stable` instead?of?`final`?

I think it avoids setting it to `false` when it is not `true`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1854959764

From alanb at openjdk.org  Sat Nov 23 10:03:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 23 Nov 2024 10:03:43 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
Message-ID: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>

On Fri, 22 Nov 2024 20:32:50 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.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more tests for socket connect events.
>   
>   - SocketAdapter connect
>   - SocketAdapter connect with exception
>   - Socket connect with exception
>   - SocketChannel connect with exception
>   - SocketChannel non-blocking connect
>   - SocketChannel non-blocking connect with exception

Thanks for the update, it's good to have tests for the 8 possible cases that might record a SocketConnect event. If you have the energy for it, we could also add tests to check that a SocketConnect is not recorded for cases where the connect method fails for other reasons, e.g. already connected, Socket closed, ... but only if you want.

src/java.base/share/classes/jdk/internal/event/SocketConnectEvent.java line 37:

> 35:  * {@code jdk.jfr.events.SocketConnectEvent } where the metadata for the event is
> 36:  * provided with annotations.  Some of the methods are replaced by generated
> 37:  * methods when jfr is enabled.  Note that the order of the arguments of the

In passing, there is a mix of "JFR" and "jfr" through-out, I assume you want "JFR" everywhere.

src/java.base/share/classes/jdk/internal/event/SocketConnectEvent.java line 51:

> 49: 
> 50:     /**
> 51:      * Actually commit an event.  The implementation is generated automatically.

I assume "Actually" should be removed, this method commits an event.

src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectEvent.java line 38:

> 36: @Label("Socket Connect")
> 37: @Category("Java Application")
> 38: @Description("Connecting a socket")

I wonder if we can improve on this description. The event is recorded when a connection is established or cannot be established so it's more like "Socket Connection".

test/jdk/jdk/jfr/event/io/IOHelper.java line 135:

> 133:     }
> 134: 
> 135:     public static void checkConnectionEventException(RecordedEvent event, IOException ioe) {

I assume this should checkConnectEventException.

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 157:

> 155:                         while (! sc.finishConnect()) {
> 156:                             Thread.sleep(1);
> 157:                         }

The connect method returns true if the connection is established, you should only need to poll finishConnect if the connection is not established immediately. Using a sleep is okay here (although 1ms is very low) and I'm guessing you've done this to avoid using a Selector.

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 216:

> 214:                 } catch (IOException ioe) {
> 215:                     // we expect this
> 216:                     connectException = ioe;

I think you'll need to adjust the try-catch to only set connectException if the connect or finishConnect methods fails. If the open or configureBlocking fails then connectException should not be set, instead the test should fail.

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

PR Review: https://git.openjdk.org/jdk/pull/21528#pullrequestreview-2456365810
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145320
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145369
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855145935
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855146240
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855150781
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855151098

From liach at openjdk.org  Sat Nov 23 14:35:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Nov 2024 14:35:14 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <F9VyaHKG4eUhxXIPmzFG5dGx9o-pKzB1UqlLwpiT91I=.f2d6d5fa-f414-47d6-85b5-222adcad43ef@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <-mnoOq9jXyXXL2rVP8xI_fsQb4xNHRi4qnNQcGvXEAs=.98bdcb74-c20b-44b2-a69e-1c3fc217caf3@github.com>
 <F9VyaHKG4eUhxXIPmzFG5dGx9o-pKzB1UqlLwpiT91I=.f2d6d5fa-f414-47d6-85b5-222adcad43ef@github.com>
Message-ID: <PWOicetH7Wyqm21SX6ik5L9RiKGkemIj0Y0F_3jp7Tg=.17840b1a-eda3-4084-9028-e82e0ae26514@github.com>

On Sat, 23 Nov 2024 01:09:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:
>> 
>>> 75:     static final boolean UNALIGNED = Bits.unaligned();
>>> 76: 
>>> 77:     private @Stable boolean temporary; // defaults to false
>> 
>> Any?reason this?is?`@Stable` instead?of?`final`?
>
> I think it avoids setting it to `false` when it is not `true`.

A stable means a false value cannot be constant-folded, but since java.nio is not trusted by ciField.cpp, using final is actually worse than a stable :(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1855203993

From qamai at openjdk.org  Sat Nov 23 16:33:47 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 23 Nov 2024 16:33:47 GMT
Subject: RFR: 8344912: Sharpen the return type of various internal methods in
 jdk.internal.foreign
Message-ID: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>

Hi,

This patch sharpens the return types of various internal methods. This helps the compiler to have better information when the corresponding methods are not inlined.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - sharpen the return types of various FFM internal methods

Changes: https://git.openjdk.org/jdk/pull/22344/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22344&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344912
  Stats: 193 lines in 14 files changed: 1 ins; 41 del; 151 mod
  Patch: https://git.openjdk.org/jdk/pull/22344.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22344/head:pull/22344

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

From liach at openjdk.org  Sat Nov 23 17:30:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Nov 2024 17:30:23 GMT
Subject: RFR: 8344912: Sharpen the return type of various internal methods
 in jdk.internal.foreign
In-Reply-To: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
References: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
Message-ID: <4eX4BV-zRkkZwNseYWUnvMl2as33uRn62pyrwUURjyM=.35d683f3-d64d-4c04-b4a5-d9391c623197@github.com>

On Sat, 23 Nov 2024 16:29:10 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch sharpens the return types of various internal methods. This helps the compiler to have better information when the corresponding methods are not inlined.
> 
> Please take a look and leave your reviews, thanks a lot.

I see this patch is in 2 parts:
1. Move of `AbstractMemorySegmentImpl::sessionImpl` to `scope` (a covariant override).  This involves a lot of usage updates.
2. More specific return types for many other methods.

Should these 2 be in 2 patches, as 1 has a lot of renaming changes?

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 392:

> 390: 
> 391:     @Override
> 392:     public MemorySessionImpl scope() {

Should this be `final` and `@ForceInline` to better match the old behavior of `sessionImpl`?

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

PR Review: https://git.openjdk.org/jdk/pull/22344#pullrequestreview-2456444601
PR Review Comment: https://git.openjdk.org/jdk/pull/22344#discussion_r1855230734

From qamai at openjdk.org  Sat Nov 23 17:47:52 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 23 Nov 2024 17:47:52 GMT
Subject: RFR: 8344912: Sharpen the return type of various internal methods
 in jdk.internal.foreign [v2]
In-Reply-To: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
References: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
Message-ID: <xxv8wjEpjoWRssoffHl8y5xRWE9qfI7v8exUEwf4mrI=.4ab78e0e-255e-45d7-b0b5-61328104f88e@github.com>

> Hi,
> 
> This patch sharpens the return types of various internal methods. This helps the compiler to have better information when the corresponding methods are not inlined.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  sharpen the return types of various FFM internal methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22344/files
  - new: https://git.openjdk.org/jdk/pull/22344/files/d81888fc..cf69f90f

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

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

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

From qamai at openjdk.org  Sat Nov 23 17:47:52 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 23 Nov 2024 17:47:52 GMT
Subject: RFR: 8344912: Sharpen the return type of various internal methods
 in jdk.internal.foreign [v2]
In-Reply-To: <4eX4BV-zRkkZwNseYWUnvMl2as33uRn62pyrwUURjyM=.35d683f3-d64d-4c04-b4a5-d9391c623197@github.com>
References: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
 <4eX4BV-zRkkZwNseYWUnvMl2as33uRn62pyrwUURjyM=.35d683f3-d64d-4c04-b4a5-d9391c623197@github.com>
Message-ID: <0PnJTMc3L3oRFeLxLW3W5x5EqewW96xp3TaYrTuZs9Y=.3ce189b3-8070-4650-9298-a5977460c9b9@github.com>

On Sat, 23 Nov 2024 17:27:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Quan Anh Mai has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   sharpen the return types of various FFM internal methods
>
> I see this patch is in 2 parts:
> 1. Move of `AbstractMemorySegmentImpl::sessionImpl` to `scope` (a covariant override).  This involves a lot of usage updates.
> 2. More specific return types for many other methods.
> 
> Should these 2 be in 2 patches, as 1 has a lot of renaming changes?

@liach Yes you are right, I have reverted the `scope` cleanup part.

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

PR Comment: https://git.openjdk.org/jdk/pull/22344#issuecomment-2495555588

From alanb at openjdk.org  Sat Nov 23 18:34:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 23 Nov 2024 18:34:14 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <9VhpXb_T8K7DxxTX9qzTV5OVRg3sqHr6K8ezZOsslEE=.e43da4ba-fa77-42c0-98fe-1b6d54d2067f@github.com>

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

While you are there, can you also look into not creating a Cleaner for the temporary direct buffers? They are explicitly deallocated when they can't be returned to the TL cache or when the thread terminates (there is a hook in thread exit for this).

Also, on the surface it might look we could use a thread confined Arena and allocate MemorySegments and get a BB view but these temporary buffers are actually carrier local when there are virtual threads mounted.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2495590190

From qamai at openjdk.org  Sun Nov 24 03:26:18 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 24 Nov 2024 03:26:18 GMT
Subject: RFR: 8344912: Sharpen the return type of various internal methods
 in jdk.internal.foreign [v3]
In-Reply-To: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
References: <Rat0BCaGceNbFfs01m_lOkC99g69u6gyKNdheVh4qoY=.e09ae48c-a30e-4c28-8993-6c5d2a037550@github.com>
Message-ID: <TqN8gkFybGpUAbHAmhPEV7CnsNFqHVAlqKxW27TFKso=.6fd45420-5f9d-47df-ba8b-b0d78c587b5e@github.com>

> Hi,
> 
> This patch sharpens the return types of various internal methods. This helps the compiler to have better information when the corresponding methods are not inlined.
> 
> Please take a look and leave your reviews, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix failing tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22344/files
  - new: https://git.openjdk.org/jdk/pull/22344/files/cf69f90f..d44b2ee5

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

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

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

From egahlin at openjdk.org  Sun Nov 24 23:20:15 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 24 Nov 2024 23:20:15 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
Message-ID: <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>

On Sat, 23 Nov 2024 08:02:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added more tests for socket connect events.
>>   
>>   - SocketAdapter connect
>>   - SocketAdapter connect with exception
>>   - Socket connect with exception
>>   - SocketChannel connect with exception
>>   - SocketChannel non-blocking connect
>>   - SocketChannel non-blocking connect with exception
>
> src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectEvent.java line 38:
> 
>> 36: @Label("Socket Connect")
>> 37: @Category("Java Application")
>> 38: @Description("Connecting a socket")
> 
> I wonder if we can improve on this description. The event is recorded when a connection is established or cannot be established so it's more like "Socket Connection".

As I understand it, the event succeeds if exceptionMessage is null.

Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1855573527

From pminborg at openjdk.org  Mon Nov 25 07:36:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 25 Nov 2024 07:36:18 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <KBJX6OyrasFImOfaUYb1XJkbU-S6kE_PYXmIFWF7rF8=.bce35dd4-1bf6-481d-a015-9f30075c35a6@github.com>

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

Could we add some tests also?

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2497081725

From alanb at openjdk.org  Mon Nov 25 07:57:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 07:57:22 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
Message-ID: <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>

On Sun, 24 Nov 2024 23:15:02 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway.

If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856011185

From egahlin at openjdk.org  Mon Nov 25 11:02:19 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 25 Nov 2024 11:02:19 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
Message-ID: <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>

On Mon, 25 Nov 2024 07:54:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded.

If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like:

`$ jfr view socket-connection-failures recording.jfr`

to see a complete list of failures per host/port and then have:

`$ jfr view slow-socket-connections recording.jfr`

to find which ones are slow, i.e. more than 10-20 ms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856393748

From alanb at openjdk.org  Mon Nov 25 12:03:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 12:03:16 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
Message-ID: <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>

On Mon, 25 Nov 2024 10:59:35 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> Perhaps this should be made more explicit with a failed field. Alternatively, there could be two events: one for success and one for failure. What is the typical duration of a failed event? If it is above 10-20 ms, two events might not be as useful since all failures will be recorded anyway.
>> 
>> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded.
>
>> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded.
> 
> If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like:
> 
> `$ jfr view socket-connection-failures recording.jfr`
> 
> to see a complete list of failures per host/port and then have:
> 
> `$ jfr view slow-socket-connections recording.jfr`
> 
> to find which ones are slow, i.e. more than 10-20 ms.

Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856496052

From egahlin at openjdk.org  Mon Nov 25 13:26:23 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 25 Nov 2024 13:26:23 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
Message-ID: <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>

On Mon, 25 Nov 2024 12:00:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> If a connection cannot be established then it might be immediate, 10s of milliseconds, maybe 60+ seconds in some cases. A slow down or stall waiting for a connection to be established seems a useful event to have recorded.
>> 
>> If it's immediate, a potential Socket Connection Failure event could overflow the buffers and we can't have it with threshold = 0s. Otherwise, it might be interesting to have something like:
>> 
>> `$ jfr view socket-connection-failures recording.jfr`
>> 
>> to see a complete list of failures per host/port and then have:
>> 
>> `$ jfr view slow-socket-connections recording.jfr`
>> 
>> to find which ones are slow, i.e. more than 10-20 ms.
>
> Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish?

A connection failure introduces a latency in the application, so probably best to have such an event durational as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1856610190

From duke at openjdk.org  Mon Nov 25 16:22:48 2024
From: duke at openjdk.org (Larry Cable)
Date: Mon, 25 Nov 2024 16:22:48 GMT
Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command
Message-ID: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>

c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)

Summary
-------

Add `jcmd <pid> Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads.


Problem
-------

The JDK is lacking tooling to diagnose issues with virtual threads.


Solution
--------

Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings.

Here is sample output. The output is intended for experts and is not intended for automated parsing.


Virtual thread scheduler:
java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0]

Timeout schedulers:
[0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
[1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0]
[2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
[3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]

Read I/O pollers:
[0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1]

Write I/O pollers:
[0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0]

Thread groupings:
<root> [platform threads = 11, virtual threads = 0]
java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0]
java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0]
ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0]
java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0]
java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0]
java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2]
ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0]
java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845 [platform threads = 1, virtual threads = 0]


The "Virtual thread scheduler" section show the target parallelism, the number of threads in the scheduler's pool, and other useful counters.

The "Timeout schedulers" section provides information on the usage of the ScheduledThreadPoolExecutor used to support virtual thread doing timed operations.

The "I/O pollers" section will vary by OS. The sample output here is macOS which, by default, has a one read and one write poller. This is useful to see how many blocking network I/O operations on virtual threads are in progress.

The "Thread groupings" appears a support people to get a sense of how the virtual threads are grouped. Virtual threads created directly with the Thread API are in the "root" grouping. Some servers may have one or more ThreadPerTaskExecutor instances. For now, this section doesn't print the tree of thread groupings that arises when using the Structured Concurrency API.


Specification
-------------

The output from `jcmd <pid> Thread.vthread_summary -help` is:


Thread.vthread_summary`
   Print the virtual thread scheduler, timeout schedulers, I/O pollers, and thread groupings.

   Impact: Low

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

Commit messages:
 - JDK-8337199: removed thread groupings iimpl from dcmd as per Alan B, and disabled asssociated tests
 - JDK-8337199: merge master
 - Sync with loom repo
 - Sync up from loom repo
 - Update from loom repo
 - Initial commit

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

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

From alanb at openjdk.org  Mon Nov 25 16:52:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 16:52:20 GMT
Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command
In-Reply-To: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
References: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
Message-ID: <mZClGX24CK2nr04ZWsoAB0JYUZfcvcteve7bLbkLQqw=.1eadefbe-86f4-4faf-a681-ce3319bfa7cc@github.com>

On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable <duke at openjdk.org> wrote:

> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
> 
> Summary
> -------
> 
> Add `jcmd <pid> Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads.
> 
> 
> Problem
> -------
> 
> The JDK is lacking tooling to diagnose issues with virtual threads.
> 
> 
> Solution
> --------
> 
> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings.
> 
> Here is sample output. The output is intended for experts and is not intended for automated parsing.
> 
> 
> Virtual thread scheduler:
> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0]
> 
> Timeout schedulers:
> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0]
> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> 
> Read I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1]
> 
> Write I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0]
> 
> Thread groupings:
> <root> [platform threads = 11, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0]
> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2]
> ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0]
> java.util.concurrent.Scheduled...

In the CSR I think we've agreed to drop the thread groupings from this command. Can you update the Solution section so the sample output aligns with that?

The PR shows merge conflicts, can you sync up the branch to closer to main line? The man page update moves from jcmd.1 to jcmd.md. Drop "thread groupings" from the description, and also  VThreadSummaryDCmd::description (diagnosticCommand.hpp).

I see the commit to comment out printing the thread groupings but I think better to remove the unused code. You can grab the latest VThreadSummary.java and VThreadSummaryTest.java from the loom repo. Also can you grab Poller.java too as it has the correct merge with JEP 491.

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

PR Comment: https://git.openjdk.org/jdk/pull/22121#issuecomment-2498536459

From bpb at openjdk.org  Mon Nov 25 17:11:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 17:11:21 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <KBJX6OyrasFImOfaUYb1XJkbU-S6kE_PYXmIFWF7rF8=.bce35dd4-1bf6-481d-a015-9f30075c35a6@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <KBJX6OyrasFImOfaUYb1XJkbU-S6kE_PYXmIFWF7rF8=.bce35dd4-1bf6-481d-a015-9f30075c35a6@github.com>
Message-ID: <n_D9tTKh-1zUM4HoADmE7M1vnGzLQAb88gAKiuyGT5w=.9a06f216-58b3-4aee-bed1-3c07b934a89e@github.com>

On Mon, 25 Nov 2024 07:33:10 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Could we add some tests also?

Do you have any suggestions? That the buffers do not affect the memory limit is implicitly tested by the tests associated with the issues linked in Jira.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2498578224

From bpb at openjdk.org  Mon Nov 25 17:24:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 17:24:19 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <9VhpXb_T8K7DxxTX9qzTV5OVRg3sqHr6K8ezZOsslEE=.e43da4ba-fa77-42c0-98fe-1b6d54d2067f@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <9VhpXb_T8K7DxxTX9qzTV5OVRg3sqHr6K8ezZOsslEE=.e43da4ba-fa77-42c0-98fe-1b6d54d2067f@github.com>
Message-ID: <AQvjYnUT7kqwnS5m22MxPthGm1zgTvUBOuegJ289Fl8=.b520d991-0c9a-46d4-9ce2-68a193cb9267@github.com>

On Sat, 23 Nov 2024 18:31:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> While you are there, can you also look into not creating a Cleaner for the temporary direct buffers? They are explicitly deallocated when they can't be returned to the TL cache or when the thread terminates (there is a hook in thread exit for this).

At present the explicit deallocation uses the cleaner:

    private static void free(ByteBuffer buf) {
        ((DirectBuffer)buf).cleaner().clean();
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2498608413

From alanb at openjdk.org  Mon Nov 25 17:28:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 17:28:13 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <AQvjYnUT7kqwnS5m22MxPthGm1zgTvUBOuegJ289Fl8=.b520d991-0c9a-46d4-9ce2-68a193cb9267@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <9VhpXb_T8K7DxxTX9qzTV5OVRg3sqHr6K8ezZOsslEE=.e43da4ba-fa77-42c0-98fe-1b6d54d2067f@github.com>
 <AQvjYnUT7kqwnS5m22MxPthGm1zgTvUBOuegJ289Fl8=.b520d991-0c9a-46d4-9ce2-68a193cb9267@github.com>
Message-ID: <vl8qAekNJMPte-ApsdG944ixRLPj9omjC4gjbgl6L0w=.34ed3616-9994-42e1-8c4b-1e1b6b34fd7d@github.com>

On Mon, 25 Nov 2024 17:21:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> At present the explicit deallocation uses the cleaner:

Right but if we change this then you should find the "temporary" field goes away as it will be different deallocator.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2498618105

From bpb at openjdk.org  Mon Nov 25 18:51:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 18:51:48 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v2]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: Do not create Cleaner for temporary buffers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/5640acb7..b68ee5f0

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

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

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

From alanb at openjdk.org  Mon Nov 25 19:09:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 19:09:16 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v2]
In-Reply-To: <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
Message-ID: <eHsESE7ntGdNHa3nTIcu6SVBLOE12_9S6h9zOi2lReE=.5f1cf33c-6814-4a97-8fdf-31ed2a995e75@github.com>

On Mon, 25 Nov 2024 18:51:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: Do not create Cleaner for temporary buffers

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:

> 75:     static final boolean UNALIGNED = Bits.unaligned();
> 76: 
> 77:     private @Stable boolean temporary; // defaults to false

Is this used now?

src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 73:

> 71:      * Used by {@code sun.nio.ch.Util}.
> 72:      */
> 73:     ByteBuffer allocateDirectTemporary(int cap);

In Util, the phrase used is "temporary buffer and the methods are named like getTemporaryDirectBuffer. The SharedSecrets transposes the words, don't know if that was intended or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857208729
PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857210986

From alanb at openjdk.org  Mon Nov 25 19:13:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 19:13:15 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v2]
In-Reply-To: <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
Message-ID: <4O_5AxF3x5cgTA8GYQ0oigQ_KB9sHxzoi3ubkzxFKUU=.9dfcb6f8-ad5d-4341-b927-5f830e07364a@github.com>

On Mon, 25 Nov 2024 18:51:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: Do not create Cleaner for temporary buffers

One thing we'll need to think about is observability. There may be an argument to track the usage as a buffer pool "temporary-direct" to add to the 3 pools that are currently exposed by BufferPoolMXBean.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2498828545

From bpb at openjdk.org  Mon Nov 25 19:13:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 19:13:19 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v2]
In-Reply-To: <eHsESE7ntGdNHa3nTIcu6SVBLOE12_9S6h9zOi2lReE=.5f1cf33c-6814-4a97-8fdf-31ed2a995e75@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
 <eHsESE7ntGdNHa3nTIcu6SVBLOE12_9S6h9zOi2lReE=.5f1cf33c-6814-4a97-8fdf-31ed2a995e75@github.com>
Message-ID: <pfSptXtZfCkleN9Tn1dVGo6Zk6jPVTJnTY6cY61m4ZM=.40945b88-8f0b-4fbc-9b80-b0cedd83c733@github.com>

On Mon, 25 Nov 2024 19:04:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344882: Do not create Cleaner for temporary buffers
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:
> 
>> 75:     static final boolean UNALIGNED = Bits.unaligned();
>> 76: 
>> 77:     private @Stable boolean temporary; // defaults to false
> 
> Is this used now?

No. I removed it in a version I did not check in but forgot here.

> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 73:
> 
>> 71:      * Used by {@code sun.nio.ch.Util}.
>> 72:      */
>> 73:     ByteBuffer allocateDirectTemporary(int cap);
> 
> In Util, the phrase used is "temporary buffer and the methods are named like getTemporaryDirectBuffer. The SharedSecrets transposes the words, don't know if that was intended or not.

It was intended but I think they should match. I'll change the on in JavaNioAccess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857215085
PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857215672

From bpb at openjdk.org  Mon Nov 25 19:22:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 19:22:51 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v2]
In-Reply-To: <pfSptXtZfCkleN9Tn1dVGo6Zk6jPVTJnTY6cY61m4ZM=.40945b88-8f0b-4fbc-9b80-b0cedd83c733@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <gw3NAUhA2VsayrSPucNgw14REn_BgF-eocWLrBjNnik=.60cfad11-bcf4-4a7c-8a02-76fdb399fdfe@github.com>
 <eHsESE7ntGdNHa3nTIcu6SVBLOE12_9S6h9zOi2lReE=.5f1cf33c-6814-4a97-8fdf-31ed2a995e75@github.com>
 <pfSptXtZfCkleN9Tn1dVGo6Zk6jPVTJnTY6cY61m4ZM=.40945b88-8f0b-4fbc-9b80-b0cedd83c733@github.com>
Message-ID: <fFGFnStC-kGLHdNtiKU_RNHI5ldK7dJF3wGV_D4WdSw=.f8207c83-7bb3-40a0-a971-963a9a7a2735@github.com>

On Mon, 25 Nov 2024 19:10:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 77:
>> 
>>> 75:     static final boolean UNALIGNED = Bits.unaligned();
>>> 76: 
>>> 77:     private @Stable boolean temporary; // defaults to false
>> 
>> Is this used now?
>
> No. I removed it in a version I did not check in but forgot here.

Changed in [9d84aa9](https://github.com/openjdk/jdk/pull/22339/commits/9d84aa9cfd718265c72e26eff9434f8817d25d80).

>> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 73:
>> 
>>> 71:      * Used by {@code sun.nio.ch.Util}.
>>> 72:      */
>>> 73:     ByteBuffer allocateDirectTemporary(int cap);
>> 
>> In Util, the phrase used is "temporary buffer and the methods are named like getTemporaryDirectBuffer. The SharedSecrets transposes the words, don't know if that was intended or not.
>
> It was intended but I think they should match. I'll change the on in JavaNioAccess.

Changed in https://github.com/openjdk/jdk/pull/22339/commits/9d84aa9cfd718265c72e26eff9434f8817d25d80.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857224962
PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857225219

From bpb at openjdk.org  Mon Nov 25 19:22:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 19:22:51 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v3]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <LsYuvmCtxnw1g7b639jcXTIid-bLzWVUyrFscHOcJYI=.de75d2ae-1544-4bf4-8af7-ebba8e327567@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: Remove DirectBuffer.temporary; rename JavaNioAccess temporary direct buffer allocation method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/b68ee5f0..9d84aa9c

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

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

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

From alanb at openjdk.org  Mon Nov 25 19:28:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 25 Nov 2024 19:28:15 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v3]
In-Reply-To: <LsYuvmCtxnw1g7b639jcXTIid-bLzWVUyrFscHOcJYI=.de75d2ae-1544-4bf4-8af7-ebba8e327567@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <LsYuvmCtxnw1g7b639jcXTIid-bLzWVUyrFscHOcJYI=.de75d2ae-1544-4bf4-8af7-ebba8e327567@github.com>
Message-ID: <oMP--lSLMc8GOG53sUzHu1O1xe9f85RzbgK1vx5lf0w=.1c6b1f68-84f1-44ec-aca6-5eecc5aaff97@github.com>

On Mon, 25 Nov 2024 19:22:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: Remove DirectBuffer.temporary; rename JavaNioAccess temporary direct buffer allocation method

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 44:

> 42: #if[byte]
> 43: import jdk.internal.vm.annotation.Stable;
> 44: #end[byte]

I assume this isn't needed either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857232841

From bpb at openjdk.org  Mon Nov 25 19:55:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 19:55:46 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v4]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: Remove vestigial import of Stable annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/9d84aa9c..4e4cdbb3

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

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

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

From bpb at openjdk.org  Mon Nov 25 20:30:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 25 Nov 2024 20:30:30 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v3]
In-Reply-To: <oMP--lSLMc8GOG53sUzHu1O1xe9f85RzbgK1vx5lf0w=.1c6b1f68-84f1-44ec-aca6-5eecc5aaff97@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <LsYuvmCtxnw1g7b639jcXTIid-bLzWVUyrFscHOcJYI=.de75d2ae-1544-4bf4-8af7-ebba8e327567@github.com>
 <oMP--lSLMc8GOG53sUzHu1O1xe9f85RzbgK1vx5lf0w=.1c6b1f68-84f1-44ec-aca6-5eecc5aaff97@github.com>
Message-ID: <xNMOFEuVue2soLhumNXky0N5X6KXEsXhnEdWnP4CJy4=.1b64f0a1-0b7d-4546-b635-4503d1956c62@github.com>

On Mon, 25 Nov 2024 19:25:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344882: Remove DirectBuffer.temporary; rename JavaNioAccess temporary direct buffer allocation method
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 44:
> 
>> 42: #if[byte]
>> 43: import jdk.internal.vm.annotation.Stable;
>> 44: #end[byte]
> 
> I assume this isn't needed either.

Removed in 4e4cdbb.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22339#discussion_r1857303844

From alanb at openjdk.org  Tue Nov 26 06:57:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 06:57:42 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v4]
In-Reply-To: <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
Message-ID: <uugrKb-tUsQpkLSdu9KlAJ58c25jHVgC-OQimkp9uEY=.74c42bc2-e411-4880-b754-eb0730b1f044@github.com>

On Mon, 25 Nov 2024 19:55:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: Remove vestigial import of Stable annotation

I think you can simplify this more by allocating with Unsafe and use the DirectByteBuffer(int, long) constructor. That would avoid needing the DBB code to know anything about temporary buffers and also means the allocate/free with using Unsafe in one place rather than assume that DirectByteBuffer uses Unsafe. The SharedSecrets would change to newDirectBuffer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2499805511

From marchof at openjdk.org  Tue Nov 26 07:32:33 2024
From: marchof at openjdk.org (Marc R. Hoffmann)
Date: Tue, 26 Nov 2024 07:32:33 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function
Message-ID: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>

With JDK-8343785 all usages of this method have been eliminated.

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

Commit messages:
 - 8345015: Remove unused lookup_time_t_function

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

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

From marchof at openjdk.org  Tue Nov 26 07:35:52 2024
From: marchof at openjdk.org (Marc R. Hoffmann)
Date: Tue, 26 Nov 2024 07:35:52 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function [v2]
In-Reply-To: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
Message-ID: <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>

> With JDK-8343785 all usages of this method have been eliminated.

Marc R. Hoffmann has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8345015: Remove unused method lookup_time_t_function
  
  With JDK-8343785 all usages of this method have
  been eliminated.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22383/files
  - new: https://git.openjdk.org/jdk/pull/22383/files/220e90a9..085d6f12

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

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

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

From alanb at openjdk.org  Tue Nov 26 07:48:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 07:48:51 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function [v2]
In-Reply-To: <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
 <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
Message-ID: <1X-VNCyhUVE4VhnkDiBnPNm1Cuj1wE4SAMwzcz_8Fcs=.904dfb26-f385-4dca-914f-3c49db68c30d@github.com>

On Tue, 26 Nov 2024 07:35:52 GMT, Marc R. Hoffmann <marchof at openjdk.org> wrote:

>> With JDK-8343785 all usages of this method have been eliminated.
>
> Marc R. Hoffmann has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8345015: Remove unused method lookup_time_t_function
>   
>   With JDK-8343785 all usages of this method have
>   been eliminated.

@vpa1977  Have you tested on Ubuntu noble armhf recently? This code was added for that build, it has since become orphaned so need to decide if it can be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22383#issuecomment-2499894704

From alanb at openjdk.org  Tue Nov 26 08:17:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 08:17:38 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function [v2]
In-Reply-To: <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
 <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
Message-ID: <Ie-m2oPOioDzgGPNHFTbHhdPmIMVqaJ2tABcdWeRzmc=.dde4e74d-36b0-4b30-935b-ebf99d46722a@github.com>

On Tue, 26 Nov 2024 07:35:52 GMT, Marc R. Hoffmann <marchof at openjdk.org> wrote:

>> With JDK-8343785 all usages of this method have been eliminated.
>
> Marc R. Hoffmann has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8345015: Remove unused method lookup_time_t_function
>   
>   With JDK-8343785 all usages of this method have
>   been eliminated.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22383#pullrequestreview-2460716896

From marchof at openjdk.org  Tue Nov 26 08:21:43 2024
From: marchof at openjdk.org (Marc R. Hoffmann)
Date: Tue, 26 Nov 2024 08:21:43 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function [v2]
In-Reply-To: <1X-VNCyhUVE4VhnkDiBnPNm1Cuj1wE4SAMwzcz_8Fcs=.904dfb26-f385-4dca-914f-3c49db68c30d@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
 <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
 <1X-VNCyhUVE4VhnkDiBnPNm1Cuj1wE4SAMwzcz_8Fcs=.904dfb26-f385-4dca-914f-3c49db68c30d@github.com>
Message-ID: <_uuLGv8jNgHyo69AyNXPTsYxLBTowuU-zjjczqheXXo=.b0bed86f-a673-4fdc-889d-29781354b189@github.com>

On Tue, 26 Nov 2024 07:45:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Marc R. Hoffmann has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8345015: Remove unused method lookup_time_t_function
>>   
>>   With JDK-8343785 all usages of this method have
>>   been eliminated.
>
> @vpa1977  Have you tested on Ubuntu noble armhf recently? This code was added for that build, it has since become orphaned so need to decide if it can be removed.

@AlanBateman @vpa1977  As I'm not a committer can you please sponsor this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/22383#issuecomment-2499955403

From alanb at openjdk.org  Tue Nov 26 08:44:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 08:44:38 GMT
Subject: RFR: 8345015: Remove unused lookup_time_t_function [v2]
In-Reply-To: <_uuLGv8jNgHyo69AyNXPTsYxLBTowuU-zjjczqheXXo=.b0bed86f-a673-4fdc-889d-29781354b189@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
 <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
 <1X-VNCyhUVE4VhnkDiBnPNm1Cuj1wE4SAMwzcz_8Fcs=.904dfb26-f385-4dca-914f-3c49db68c30d@github.com>
 <_uuLGv8jNgHyo69AyNXPTsYxLBTowuU-zjjczqheXXo=.b0bed86f-a673-4fdc-889d-29781354b189@github.com>
Message-ID: <k2DgXdThne7QxnxRQ03zc33exiMdAbnTUvdWrbtA9iw=.5a169057-aca7-4cd0-b27b-d52df1ae2006@github.com>

On Tue, 26 Nov 2024 08:18:57 GMT, Marc R. Hoffmann <marchof at openjdk.org> wrote:

>> @vpa1977  Have you tested on Ubuntu noble armhf recently? This code was added for that build, it has since become orphaned so need to decide if it can be removed.
>
> @AlanBateman @vpa1977  As I'm not a committer can you please sponsor this PR?

@marchof You need to add "/integrate" as a comment, then any Committer can sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/22383#issuecomment-2500005230

From duke at openjdk.org  Tue Nov 26 13:08:43 2024
From: duke at openjdk.org (duke)
Date: Tue, 26 Nov 2024 13:08:43 GMT
Subject: RFR: 8345015: Remove unused method lookup_time_t_function [v2]
In-Reply-To: <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
 <OKNUhooOzxIYQrcKktit3aoMYZZDPFQIIRgOZluDYZQ=.ba19fc34-b2d6-4508-aab9-7a7da32cc583@github.com>
Message-ID: <BiYva3beapR61DGW7yF0IVgoor0EFTryUmkWSJPL8zg=.28cd9e49-a24c-4ffe-87fd-928140ec54b2@github.com>

On Tue, 26 Nov 2024 07:35:52 GMT, Marc R. Hoffmann <marchof at openjdk.org> wrote:

>> With JDK-8343785 all usages of this method have been eliminated.
>
> Marc R. Hoffmann has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8345015: Remove unused method lookup_time_t_function
>   
>   With JDK-8343785 all usages of this method have
>   been eliminated.

@marchof 
Your change (at version 085d6f12912326d8c953d0ea4f4f4c84534819f5) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22383#issuecomment-2500754315

From marchof at openjdk.org  Tue Nov 26 15:12:45 2024
From: marchof at openjdk.org (Marc R. Hoffmann)
Date: Tue, 26 Nov 2024 15:12:45 GMT
Subject: Integrated: 8345015: Remove unused method lookup_time_t_function
In-Reply-To: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
References: <Q7ZIWoDrt5X_56-0kQug39cACdThtTdFgGN71R674Uo=.b0a87ecf-2bd2-421f-bb7e-b7d17c46a5cc@github.com>
Message-ID: <ospEvHLxPij5l-yl-8spHrHlrUj0m4GCTEnn5Gt2Ff4=.c29a5069-2fce-4ac8-a440-52a2d59b3e52@github.com>

On Tue, 26 Nov 2024 07:26:14 GMT, Marc R. Hoffmann <marchof at openjdk.org> wrote:

> With JDK-8343785 all usages of this method have been eliminated.

This pull request has now been integrated.

Changeset: c329f97f
Author:    Marc R. Hoffmann <marchof at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c329f97f3211bc14aa4211461bb9a7abb073296e
Stats:     17 lines in 1 file changed: 0 ins; 17 del; 0 mod

8345015: Remove unused method lookup_time_t_function

Reviewed-by: alanb

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

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

From dfuchs at openjdk.org  Tue Nov 26 16:03:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 26 Nov 2024 16:03:13 GMT
Subject: RFR: 8344184: Remove sun.net.ResourceManager after JEP 486 integration
Message-ID: <GcZUV-lHtzft4iAvbVXjQDu6xdEbFBqSLmQh4feqKW0=.48635d07-5cd3-4e37-8ec4-9432814f28ed@github.com>

Now that JEP 486 has been integrated the sun.net.ResourceManager class has no purpose and can be removed.

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

Commit messages:
 - 8344184: Remove sun.net.ResourceManager after JEP 486 integration

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

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

From bpb at openjdk.org  Tue Nov 26 16:07:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:07:41 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v4]
In-Reply-To: <uugrKb-tUsQpkLSdu9KlAJ58c25jHVgC-OQimkp9uEY=.74c42bc2-e411-4880-b754-eb0730b1f044@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
 <uugrKb-tUsQpkLSdu9KlAJ58c25jHVgC-OQimkp9uEY=.74c42bc2-e411-4880-b754-eb0730b1f044@github.com>
Message-ID: <uPyORQduCKl1r94Hwq8cQCLtd1sLOHy5akHe3qICy1A=.66b757fe-9e39-4cd5-a0b2-5af4300397ff@github.com>

On Tue, 26 Nov 2024 06:55:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the DirectByteBuffer(int, long) constructor

I think you intend the constructor which is now

    private Direct$Type$Buffer(long addr, long cap) {

at line 172 in the latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2501256277

From bpb at openjdk.org  Tue Nov 26 16:07:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:07:42 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v4]
In-Reply-To: <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
Message-ID: <rxzQr4foHYTFmC36gcwM0y28MLsIM3_XVPcs9A-1QH4=.168d26d5-fa6e-4c3f-ae47-eb05e6def909@github.com>

On Mon, 25 Nov 2024 19:55:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: Remove vestigial import of Stable annotation

> /label remove security

Thanks. I did not know why that was added.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2501258683

From bpb at openjdk.org  Tue Nov 26 16:09:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:09:51 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
 allocate all direct buffer memory [v3]
In-Reply-To: <-LvX-iXqsW7StJQ22bEcZjI6-_rrA7doVsvyo_GMmhI=.22850b66-edea-4196-9544-47c84069bbae@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
 <-LvX-iXqsW7StJQ22bEcZjI6-_rrA7doVsvyo_GMmhI=.22850b66-edea-4196-9544-47c84069bbae@github.com>
Message-ID: <aOAX3wGHQlZlxw_DnOsjRvdhm6yBNNialYyLcdI0dI4=.d726b38c-d94e-41f4-a7b3-021127a2ab4c@github.com>

On Mon, 28 Oct 2024 22:09:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340728: Fail if too much direct memory was allocated before this test is run

This request will likely be withdrawn when #22339 is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/21623#issuecomment-2501261791

From alanb at openjdk.org  Tue Nov 26 16:09:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 16:09:42 GMT
Subject: RFR: 8344184: Remove sun.net.ResourceManager after JEP 486
 integration
In-Reply-To: <GcZUV-lHtzft4iAvbVXjQDu6xdEbFBqSLmQh4feqKW0=.48635d07-5cd3-4e37-8ec4-9432814f28ed@github.com>
References: <GcZUV-lHtzft4iAvbVXjQDu6xdEbFBqSLmQh4feqKW0=.48635d07-5cd3-4e37-8ec4-9432814f28ed@github.com>
Message-ID: <rs0NbVgu-btsPZ5GBuTURO71u4jMxk3-voo_qH9WbEI=.900d0451-3034-4c2f-b3a9-f32e0ceac946@github.com>

On Tue, 26 Nov 2024 15:56:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Now that JEP 486 has been integrated the sun.net.ResourceManager class has no purpose and can be removed.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22394#pullrequestreview-2462012684

From bpb at openjdk.org  Tue Nov 26 16:39:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:39:57 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v5]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <5271ZJkwTZqWpY5kBfnouO7Z3A865BwfaA8_R4DTaRk=.2acc31b2-acda-4cc3-a6a1-a69bf0525b93@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: Remove local field "temporary" by using an alternate constructor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/4e4cdbb3..1d7588a5

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

  Stats: 30 lines in 4 files changed: 3 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/22339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22339/head:pull/22339

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

From bpb at openjdk.org  Tue Nov 26 16:39:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:39:57 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v4]
In-Reply-To: <uugrKb-tUsQpkLSdu9KlAJ58c25jHVgC-OQimkp9uEY=.74c42bc2-e411-4880-b754-eb0730b1f044@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <0uyB4_igWljZP6WwR36A65EoCWwVuz3wz_EmJ6KwAvo=.9db88d43-0b6a-47b7-b3f3-7661e8fae66c@github.com>
 <uugrKb-tUsQpkLSdu9KlAJ58c25jHVgC-OQimkp9uEY=.74c42bc2-e411-4880-b754-eb0730b1f044@github.com>
Message-ID: <8E2ctiJeZatJt-g3x94Y55IHBxymASw9SEvxe5lPctM=.e601c537-f3b3-4f9a-b078-c5cc8a148645@github.com>

On Tue, 26 Nov 2024 06:55:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you can simplify this more by allocating with Unsafe and use the DirectByteBuffer(int, long) constructor.

Changed as suggested in 1d7588a.

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

PR Comment: https://git.openjdk.org/jdk/pull/22339#issuecomment-2501357138

From ole.sh at gmx.de  Tue Nov 26 16:44:45 2024
From: ole.sh at gmx.de (ole.sh at gmx.de)
Date: Tue, 26 Nov 2024 16:44:45 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
Message-ID: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>

Hi,

I came a across a behavior of Files.createDirectories on Linux (RHEL8, JDK 17) that is a litte "unexpected":
The call of Files.createDirectories for an existing (and readable) directory on an NFS mount throws an AccessDeniedException. Technically this exception is correct because our process does not have the filesystem rights to create the directory, the process does have the rights to "read" the directory though. Looking at the JavaDoc of Files.createDirectories my expectation was that no exception would be thrown because the directory exists. I know that Files.createDirectories may throw an IOException and thus an AccessDeniedException but - as I said - it is a little "unexpected". What was even more suprising is that for the same directory the call to Files.createDirectories sometimes works and sometimes throws an AccessDeniedException (using the same process, user, etc. of course).

I took a closer look at it and saw that Files.createDirectories never explicitly checks for the existence of the directory but relies on the createDirectory of the underlying FileSystemProvider to throw an FileAlreadyExistsException. In case of Linux the underlying UnixFileSystemProvider calls the mkdir system call and checks/translates its return code. The problem is that the mkdir system call seems to be allowed (according to Posix?) to return any of the matching return codes in case multiple return codes are "correct". And that happens in our NFS case. We verified that the mkdir call sometimes returns EACCESS and sometimes EEXIST (most likely due to some "caching" in the kernel NFS driver).

Although it is just an "edge case" I wonder if it makes sense to make Files.createDirectories more "predictable" in such cases? A simple solution might be to adapt Files.createAndCheckIsDirectory to check if the "dir" is a  directory not just in case of an FileAlreadyExistsException but also in case of an AccessDeniedException:

    private static void createAndCheckIsDirectory(Path dir,
                                                  FileAttribute<!--?-->... attrs)
        throws IOException
    {
        try {
            createDirectory(dir, attrs);
        } catch (FileAlreadyExistsException x) {
            if (!isDirectory(dir))
                throw x;
+       } catch (AccessDeniedException x) {
+           if (!isDirectory(dir))
+              throw x;
        }
    }

Some additional notes:
* A similar problem was reported and fixed in JDK-8032220 for MacOS and Windows
* Though I have this problem using JDK 17 it (most likely) also could occur with the latest JDK because the implementation of Files.createDirectories seems not to have changed much.

Best regards
Ole

From bpb at openjdk.org  Tue Nov 26 16:58:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 16:58:53 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v6]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <0st-9UTdvAGu6D5CVdYHPGjagj8cV4HtMNZJNCaxUi4=.8e7ed63d-bdab-44e7-91a4-f9921ac2d0e8@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: Make allocate+free be only in Util

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/1d7588a5..c27de5a3

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

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

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

From bpb at openjdk.org  Tue Nov 26 18:53:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 26 Nov 2024 18:53:58 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v7]
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <z6MIjh2RDbF4qJmefc37ARjHlVcf02qlUgAZXvFZDmo=.92aea26f-5d7f-4d5f-b4c1-ade06a583617@github.com>

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

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

  8344882: If the buffer is a slice, free it's parent's address

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22339/files
  - new: https://git.openjdk.org/jdk/pull/22339/files/c27de5a3..80d6551d

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

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

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

From alanb at openjdk.org  Tue Nov 26 20:21:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 26 Nov 2024 20:21:38 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v7]
In-Reply-To: <z6MIjh2RDbF4qJmefc37ARjHlVcf02qlUgAZXvFZDmo=.92aea26f-5d7f-4d5f-b4c1-ade06a583617@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <z6MIjh2RDbF4qJmefc37ARjHlVcf02qlUgAZXvFZDmo=.92aea26f-5d7f-4d5f-b4c1-ade06a583617@github.com>
Message-ID: <JEsWC8fA3mLJRnGUubJf6kwHoSjWS9z-GOcp82n0-OA=.3e0913d8-c6a2-413d-ab70-ddd030ba1cd8@github.com>

On Tue, 26 Nov 2024 18:53:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: If the buffer is a slice, free it's parent's address

I think you've got this to a good place.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22339#pullrequestreview-2462593213

From dfuchs at openjdk.org  Tue Nov 26 20:50:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 26 Nov 2024 20:50:43 GMT
Subject: Integrated: 8344184: Remove sun.net.ResourceManager after JEP 486
 integration
In-Reply-To: <GcZUV-lHtzft4iAvbVXjQDu6xdEbFBqSLmQh4feqKW0=.48635d07-5cd3-4e37-8ec4-9432814f28ed@github.com>
References: <GcZUV-lHtzft4iAvbVXjQDu6xdEbFBqSLmQh4feqKW0=.48635d07-5cd3-4e37-8ec4-9432814f28ed@github.com>
Message-ID: <GZBPIears1dvHpq6kj74wn4h24z3p8sSPrmkr0YuqKY=.6f2c92f1-7304-41cc-a418-e9842361dae0@github.com>

On Tue, 26 Nov 2024 15:56:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Now that JEP 486 has been integrated the sun.net.ResourceManager class has no purpose and can be removed.

This pull request has now been integrated.

Changeset: 7ae6069e
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7ae6069ee8b9815a35d3b6d976b59d30c96a4837
Stats:     109 lines in 3 files changed: 0 ins; 102 del; 7 mod

8344184: Remove sun.net.ResourceManager after JEP 486 integration

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22394

From brian.burkhalter at oracle.com  Tue Nov 26 22:49:06 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 26 Nov 2024 22:49:06 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
Message-ID: <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>

Hi Ole,

On Nov 26, 2024, at 8:44?AM, ole.sh at gmx.de wrote:

I came a across a behavior of Files.createDirectories on Linux (RHEL8, JDK 17) that is a litte "unexpected":
The call of Files.createDirectories for an existing (and readable) directory on an NFS mount throws an AccessDeniedException. Technically this exception is correct because our process does not have the filesystem rights to create the directory, the process does have the rights to "read" the directory though. Looking at the JavaDoc of Files.createDirectories my expectation was that no exception would be thrown because the directory exists. I know that Files.createDirectories may throw an IOException and thus an AccessDeniedException but - as I said - it is a little "unexpected". What was even more suprising is that for the same directory the call to Files.createDirectories sometimes works and sometimes throws an AccessDeniedException (using the same process, user, etc. of course).

This sounds like correct behavior driven by whatever errno the mkdir system call reports. If the target is a directory, then one would not expect an exception for EEXISTS but would expect an AccessDeniedException for EACCES.

I took a closer look at it and saw that Files.createDirectories never explicitly checks for the existence of the directory but relies on the createDirectory of the underlying FileSystemProvider to throw an FileAlreadyExistsException. In case of Linux the underlying UnixFileSystemProvider calls the mkdir system call and checks/translates its return code.

I assume that you intend the system call itself here, as the JNI interface to the system call does not translate the errno value.

The problem is that the mkdir system call seems to be allowed (according to Posix?) to return any of the matching return codes in case multiple return codes are "correct?. And that happens in our NFS case.

Do you have a link to documentation of this behavior  / specification?

We verified that the mkdir call sometimes returns EACCESS and sometimes EEXIST (most likely due to some "caching" in the kernel NFS driver).

That sounds like flakiness in the system itself, not in Java, perhaps an NFS configuration issue? It seems that Java is responding as expected to the errno values encontered.

Although it is just an "edge case" I wonder if it makes sense to make Files.createDirectories more "predictable" in such cases? A simple solution might be to adapt Files.createAndCheckIsDirectory to check if the "dir" is a  directory not just in case of an FileAlreadyExistsException but also in case of an AccessDeniedException:

   private static void createAndCheckIsDirectory(Path dir,
                                                 FileAttribute<!--?-->... attrs)
       throws IOException
   {
       try {
           createDirectory(dir, attrs);
       } catch (FileAlreadyExistsException x) {
           if (!isDirectory(dir))
               throw x;
+       } catch (AccessDeniedException x) {
+           if (!isDirectory(dir))
+              throw x;

I am not sure that we want to hide the AccessDeniedException when the target is a directory. Subsequently executed code might encounter problems and it could be harder to identify the cause. Also, this code is used by all platforms, not only Linux.

       }
   }

Some additional notes:
* A similar problem was reported and fixed in JDK-8032220 for MacOS and Windows

In that issue, filtering of EISDIR was added but this appears to be an error specific to macOS.

* Though I have this problem using JDK 17 it (most likely) also could occur with the latest JDK because the implementation of Files.createDirectories seems not to have changed much.

Best regards,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20241126/3619a6e3/attachment-0001.htm>

From liach at openjdk.org  Tue Nov 26 23:19:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Nov 2024 23:19:38 GMT
Subject: RFR: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory [v7]
In-Reply-To: <z6MIjh2RDbF4qJmefc37ARjHlVcf02qlUgAZXvFZDmo=.92aea26f-5d7f-4d5f-b4c1-ade06a583617@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
 <z6MIjh2RDbF4qJmefc37ARjHlVcf02qlUgAZXvFZDmo=.92aea26f-5d7f-4d5f-b4c1-ade06a583617@github.com>
Message-ID: <Tkv85K97ZHTX_vcgA-luXs0JGeUD8VRp_hWOAqz27-k=.1ffb76e5-2c57-4266-a360-ecc5efc8357f@github.com>

On Tue, 26 Nov 2024 18:53:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344882: If the buffer is a slice, free it's parent's address

The latest revision does look much cleaner than previous iterations.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22339#pullrequestreview-2462944973

From ole.sh at gmx.de  Wed Nov 27 11:01:58 2024
From: ole.sh at gmx.de (ole.sh at gmx.de)
Date: Wed, 27 Nov 2024 11:01:58 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
 <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>
Message-ID: <trinity-b2551d7f-e364-41d1-80f3-a92de7b0e30e-1732705318022@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-r2xnf>

Hi Brian,

thanks for our reply!

&gt;&gt; I came a across a behavior of Files.createDirectories on Linux (RHEL8, JDK 17)
&gt;&gt; that is a litte "unexpected":
&gt;&gt; The call of Files.createDirectories for an existing (and readable) directory
&gt;&gt; on an NFS mount throws an AccessDeniedException. Technically this exception is
&gt;&gt; correct because our process does not have the filesystem rights to create the
&gt;&gt; directory, the process does have the rights to "read" the directory though.
&gt;&gt; Looking at the JavaDoc of Files.createDirectories my expectation was that no
&gt;&gt; exception would be thrown because the directory exists. I know that
&gt;&gt; Files.createDirectories may throw an IOException and thus an
&gt;&gt; AccessDeniedException but - as I said - it is a little "unexpected". What was
&gt;&gt; even more suprising is that for the same directory the call to
&gt;&gt; Files.createDirectories sometimes works and sometimes throws an
&gt;&gt; AccessDeniedException (using the same process, user, etc. of course).
&gt; This sounds like correct behavior driven by whatever errno the mkdir system call
&gt; reports. If the target is a directory, then one would not expect an exception
&gt; for EEXISTS but would expect an AccessDeniedException for EACCES.
I didn't mean to say that the behavior isn't correct, it just seemed a bit "unexpected" (at least to me as a "user" of the API not knowing the details of the implementation of Files.createDirectories). 

&gt;&gt; I took a closer look at it and saw that Files.createDirectories never
&gt;&gt; explicitly checks for the existence of the directory but relies on the
&gt;&gt; createDirectory of the underlying FileSystemProvider to throw an
&gt;&gt; FileAlreadyExistsException. In case of Linux the underlying
&gt;&gt; UnixFileSystemProvider calls the mkdir system call and checks/translates its
&gt;&gt; return code.
&gt; I assume that you intend the system call itself here, as the JNI interface to
&gt; the system call does not translate the errno value.
I was referring to UnixException.translateToIOException(String, String) which is called by UnixFileSystemProvider.createDirectory. It looks like it "translates" the errno (which I guessed is the return code of the system call) to regular IOExceptions like AccessDeniedException or FileAlreadyExistsException.

&gt;&gt; The problem is that the mkdir system call seems to be allowed (according to
&gt;&gt; Posix?) to return any of the matching return codes in case multiple return
&gt;&gt; codes are "correct?. And that happens in our NFS case.
&gt; Do you have a link to documentation of this behavior / specification?
It is described in section "2.3 Error Numbers" in the "System Interfaces" volume of Posix (https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/V2_chap02.html#tag_16_03):
"
If more than one error occurs in processing a function call, any one of the possible errors may be returned, as the order of detection is undefined.
"

&gt;&gt; We verified that the mkdir call sometimes returns EACCESS and sometimes EEXIST
&gt;&gt; (most likely due to some "caching" in the kernel NFS driver).
&gt; That sounds like flakiness in the system itself, not in Java, perhaps an NFS
&gt; configuration issue? It seems that Java is responding as expected to the errno
&gt; values encontered.
I agree that it is a flakiness in the system though it seems to be "correct"/OK wrt. Posix. 

&gt;&gt; Although it is just an "edge case" I wonder if it makes sense to make
&gt;&gt; Files.createDirectories more "predictable" in such cases? A simple solution
&gt;&gt; might be to adapt Files.createAndCheckIsDirectory to check if the "dir" is a
&gt;&gt; directory not just in case of an FileAlreadyExistsException but also in case
&gt;&gt; of an AccessDeniedException:
&gt;&gt; 
&gt;&gt; private static void createAndCheckIsDirectory(Path dir,
&gt;&gt; FileAttribute<!--?-->&gt;... attrs)
&gt;&gt; throws IOException
&gt;&gt; {
&gt;&gt; try {
&gt;&gt; createDirectory(dir, attrs);
&gt;&gt; } catch (FileAlreadyExistsException x) {
&gt;&gt; if (!isDirectory(dir))
&gt;&gt; throw x;
&gt;&gt; + } catch (AccessDeniedException x) {
&gt;&gt; + if (!isDirectory(dir))
&gt;&gt; + throw x;
&gt; I am not sure that we want to hide the AccessDeniedException when the target is
&gt; a directory. Subsequently executed code might encounter problems and it could be
&gt; harder to identify the cause. Also, this code is used by all platforms, not only
Linux.
&gt;&gt; }
&gt;&gt; }
 
&gt;&gt; Some additional notes:
&gt;&gt; * A similar problem was reported and fixed in JDK-8032220 for MacOS and
&gt;&gt; Windows
&gt; In that issue, filtering of EISDIR was added but this appears to be an error
specific to macOS.
What I was referring more to were the changes made in the WindowsFileSystemProvider.createDirectory for JDK-8032220 (https://hg.openjdk.org/jdk9/jdk9/jdk/rev/8ff79b0e3503): An ERROR_ACCESS_DENIED is catched and a FileAlreadyExistException is thrown instead if the directory already exists.
In the bug ticket (https://bugs.openjdk.org/browse/JDK-8032220) it is said that "It does not appear to be an issue on Linux". This is true for the special case of "/" handled in the bug ticket. But given the behavior of mkdir regarding the return code according to Posix similar problems could/do occur on Linux (as in my NFS case)

Best regards,
Ole

From bpb at openjdk.org  Wed Nov 27 16:16:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 27 Nov 2024 16:16:46 GMT
Subject: Integrated: 8344882: (bf) Temporary direct buffers should not count
 against the upper limit on direct buffer memory
In-Reply-To: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
References: <3nzcoACiYqS0GboRr8PswKubtRVmme1Nz_6vsf54cEU=.4856b5c3-25d9-4d86-93cb-3e39c2ac43d8@github.com>
Message-ID: <SKBAWQHOyoJzd5GmSkSfn1vhOB8aLhlJqEF5ESeMeRQ=.21b60d4e-1e58-47b2-9216-1b9179bd78c5@github.com>

On Fri, 22 Nov 2024 23:44:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Make the memory used by internal temporary direct buffers not count towards the upper limit on direct buffer memory.

This pull request has now been integrated.

Changeset: 0312694c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0312694c46b4fb3455cde2e4d1f8746ad4df8548
Stats:     41 lines in 5 files changed: 30 ins; 3 del; 8 mod

8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22339

From bpb at openjdk.org  Thu Nov 28 00:09:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 28 Nov 2024 00:09:27 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v10]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <K7ep9Q_uLhtEXvhnkZzNqjlyjjuGCwtYbtWpToIPhBA=.ec57e347-bf6b-40d6-ac3c-010ed087860d@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=09
  Stats: 1547 lines in 93 files changed: 774 ins; 668 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From brian.burkhalter at oracle.com  Thu Nov 28 00:42:23 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 28 Nov 2024 00:42:23 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <trinity-b2551d7f-e364-41d1-80f3-a92de7b0e30e-1732705318022@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-r2xnf>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
 <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>
 <trinity-b2551d7f-e364-41d1-80f3-a92de7b0e30e-1732705318022@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-r2xnf>
Message-ID: <B596B512-866A-48F9-BB5F-65E7453E98B5@oracle.com>

Hi Ole,

On Nov 27, 2024, at 3:01?AM, ole.sh at gmx.de wrote:

thanks for our reply!

You are welcome!

I didn't mean to say that the behavior isn't correct, it just seemed a bit "unexpected" (at least to me as a "user" of the API not knowing the details of the implementation of Files.createDirectories).

Understood.

&gt;&gt; I took a closer look at it and saw that Files.createDirectories never
&gt;&gt; explicitly checks for the existence of the directory but relies on the
&gt;&gt; createDirectory of the underlying FileSystemProvider to throw an
&gt;&gt; FileAlreadyExistsException. In case of Linux the underlying
&gt;&gt; UnixFileSystemProvider calls the mkdir system call and checks/translates its
&gt;&gt; return code.
&gt; I assume that you intend the system call itself here, as the JNI interface to
&gt; the system call does not translate the errno value.
I was referring to UnixException.translateToIOException(String, String) which is called by UnixFileSystemProvider.createDirectory. It looks like it "translates" the errno (which I guessed is the return code of the system call) to regular IOExceptions like AccessDeniedException or FileAlreadyExistsException.

I don?t think we can translate an EACCES to AccessDeniedException here as this method is used in many places.

&gt;&gt; The problem is that the mkdir system call seems to be allowed (according to
&gt;&gt; Posix?) to return any of the matching return codes in case multiple return
&gt;&gt; codes are "correct?. And that happens in our NFS case.
&gt; Do you have a link to documentation of this behavior / specification?
It is described in section "2.3 Error Numbers" in the "System Interfaces" volume of Posix (https://urldefense.com/v3/__https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/V2_chap02.html*tag_16_03__;Iw!!ACWV5N9M2RV99hQ!MCUMndmKonwTVE9x3yuFTw-vnGgYwv6pz-A_vlT8-OVma6Q4kosEWgjYJiDxKz-L6F78hyJQrPlDbP-os2Y1$ ):
"
If more than one error occurs in processing a function call, any one of the possible errors may be returned, as the order of detection is undefined.
"

Thanks.

&gt;&gt; We verified that the mkdir call sometimes returns EACCESS and sometimes EEXIST
&gt;&gt; (most likely due to some "caching" in the kernel NFS driver).
&gt; That sounds like flakiness in the system itself, not in Java, perhaps an NFS
&gt; configuration issue? It seems that Java is responding as expected to the errno
&gt; values encontered.
I agree that it is a flakiness in the system though it seems to be "correct"/OK wrt. Posix.

That seems to be a weak point in the POSIX specification.

&gt;&gt; Although it is just an "edge case" I wonder if it makes sense to make
&gt;&gt; Files.createDirectories more "predictable" in such cases? A simple solution
&gt;&gt; might be to adapt Files.createAndCheckIsDirectory to check if the "dir" is a
&gt;&gt; directory not just in case of an FileAlreadyExistsException but also in case
&gt;&gt; of an AccessDeniedException:
&gt;&gt;
&gt;&gt; private static void createAndCheckIsDirectory(Path dir,
&gt;&gt; FileAttribute<!--?-->&gt;... attrs)
&gt;&gt; throws IOException
&gt;&gt; {
&gt;&gt; try {
&gt;&gt; createDirectory(dir, attrs);
&gt;&gt; } catch (FileAlreadyExistsException x) {
&gt;&gt; if (!isDirectory(dir))
&gt;&gt; throw x;
&gt;&gt; + } catch (AccessDeniedException x) {
&gt;&gt; + if (!isDirectory(dir))
&gt;&gt; + throw x;
&gt; I am not sure that we want to hide the AccessDeniedException when the target is
&gt; a directory. Subsequently executed code might encounter problems and it could be
&gt; harder to identify the cause. Also, this code is used by all platforms, not only
Linux.
&gt;&gt; }
&gt;&gt; }

&gt;&gt; Some additional notes:
&gt;&gt; * A similar problem was reported and fixed in JDK-8032220 for MacOS and
&gt;&gt; Windows
&gt; In that issue, filtering of EISDIR was added but this appears to be an error
specific to macOS.
What I was referring more to were the changes made in the WindowsFileSystemProvider.createDirectory for JDK-8032220 (https://hg.openjdk.org/jdk9/jdk9/jdk/rev/8ff79b0e3503): An ERROR_ACCESS_DENIED is catched and a FileAlreadyExistException is thrown instead if the directory already exists.

I see.

In the bug ticket (https://bugs.openjdk.org/browse/JDK-8032220) it is said that "It does not appear to be an issue on Linux". This is true for the special case of "/" handled in the bug ticket. But given the behavior of mkdir regarding the return code according to Posix similar problems could/do occur on Linux (as in my NFS case)

To address your problem then the safest approach would appear to be overriding createDirectory() in LinuxFileSystemProvider to have the desired behavior, such as was done on Windows.

Best regards,

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20241128/2af0b4a5/attachment-0001.htm>

From bpb at openjdk.org  Thu Nov 28 01:54:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 28 Nov 2024 01:54:45 GMT
Subject: RFR: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing to
 allocate all direct buffer memory [v3]
In-Reply-To: <-LvX-iXqsW7StJQ22bEcZjI6-_rrA7doVsvyo_GMmhI=.22850b66-edea-4196-9544-47c84069bbae@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
 <-LvX-iXqsW7StJQ22bEcZjI6-_rrA7doVsvyo_GMmhI=.22850b66-edea-4196-9544-47c84069bbae@github.com>
Message-ID: <3kxxYbetfRSStCwERmneR-No-qXFvkM1dBnAT7r2Xpc=.029ba73e-90cb-46f1-9352-7639265a9bda@github.com>

On Mon, 28 Oct 2024 22:09:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340728: Fail if too much direct memory was allocated before this test is run

This request is irrelevant now that #22339 is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21623#issuecomment-2505111530

From bpb at openjdk.org  Thu Nov 28 01:54:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 28 Nov 2024 01:54:46 GMT
Subject: Withdrawn: 8340728: Test vmTestbase/gc/memory/Nio/Nio.java is failing
 to allocate all direct buffer memory
In-Reply-To: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
References: <H8qu4AgyLXV3JAEqy3ZpyOyFC3pIvFFg4Aiy0cTgrwg=.c463eaa1-71c2-4a07-be0e-15169e2a7568@github.com>
Message-ID: <Bn-sh_BtN4MQ6jRkT5FvRyK_FO7OmVgp50ae7wabLpE=.771085f4-2b55-461d-a194-10ca09c25db5@github.com>

On Mon, 21 Oct 2024 18:22:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> First attempt to allocate `VM.maxDirectMemory()` bytes of direct buffer memory, decreasing by 1024 bytes for each `OutOfMemoryError` until allocation succeeds.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21623

From ole.sh at gmx.de  Fri Nov 29 22:13:29 2024
From: ole.sh at gmx.de (Ole SH)
Date: Fri, 29 Nov 2024 23:13:29 +0100
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <B596B512-866A-48F9-BB5F-65E7453E98B5@oracle.com>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
 <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>
 <trinity-b2551d7f-e364-41d1-80f3-a92de7b0e30e-1732705318022@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-r2xnf>
 <B596B512-866A-48F9-BB5F-65E7453E98B5@oracle.com>
Message-ID: <85ad63df-660a-4a6b-bcd3-f569e0c01af3@gmx.de>

Hi Brian,

> Hi Ole,
>
>> On Nov 27, 2024, at 3:01?AM, ole.sh at gmx.de wrote:
>>
>> thanks for our reply!
>
> You are welcome!
>
>> I didn't mean to say that the behavior isn't correct, it just seemed
>> a bit "unexpected" (at least to me as a "user" of the API not knowing
>> the details of the implementation of Files.createDirectories).
>
> Understood.
>
>> &gt;&gt; I took a closer look at it and saw that
>> Files.createDirectories never
>> &gt;&gt; explicitly checks for the existence of the directory but
>> relies on the
>> &gt;&gt; createDirectory of the underlying FileSystemProvider to throw an
>> &gt;&gt; FileAlreadyExistsException. In case of Linux the underlying
>> &gt;&gt; UnixFileSystemProvider calls the mkdir system call and
>> checks/translates its
>> &gt;&gt; return code.
>> &gt; I assume that you intend the system call itself here, as the JNI
>> interface to
>> &gt; the system call does not translate the errno value.
>> I was referring to UnixException.translateToIOException(String,
>> String) which is called by UnixFileSystemProvider.createDirectory. It
>> looks like it "translates" the errno (which I guessed is the return
>> code of the system call) to regular IOExceptions like
>> AccessDeniedException or FileAlreadyExistsException.
>
> I don?t think we can translate an EACCES to AccessDeniedException here
> as this method is used in many places.
>
>> &gt;&gt; The problem is that the mkdir system call seems to be
>> allowed (according to
>> &gt;&gt; Posix?) to return any of the matching return codes in case
>> multiple return
>> &gt;&gt; codes are "correct?. And that happens in our NFS case.
>> &gt; Do you have a link to documentation of this behavior /
>> specification?
>> It is described in section "2.3 Error Numbers" in the "System
>> Interfaces" volume of Posix
>> (https://urldefense.com/v3/__https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/V2_chap02.html*tag_16_03__;Iw!!ACWV5N9M2RV99hQ!MCUMndmKonwTVE9x3yuFTw-vnGgYwv6pz-A_vlT8-OVma6Q4kosEWgjYJiDxKz-L6F78hyJQrPlDbP-os2Y1$):
>> "
>> If more than one error occurs in processing a function call, any one
>> of the possible errors may be returned, as the order of detection is
>> undefined.
>> "
>
> Thanks.
>
>> &gt;&gt; We verified that the mkdir call sometimes returns EACCESS
>> and sometimes EEXIST
>> &gt;&gt; (most likely due to some "caching" in the kernel NFS driver).
>> &gt; That sounds like flakiness in the system itself, not in Java,
>> perhaps an NFS
>> &gt; configuration issue? It seems that Java is responding as
>> expected to the errno
>> &gt; values encontered.
>> I agree that it is a flakiness in the system though it seems to be
>> "correct"/OK wrt. Posix.
>
> That seems to be a weak point in the POSIX specification.
>
>> &gt;&gt; Although it is just an "edge case" I wonder if it makes
>> sense to make
>> &gt;&gt; Files.createDirectories more "predictable" in such cases? A
>> simple solution
>> &gt;&gt; might be to adapt Files.createAndCheckIsDirectory to check
>> if the "dir" is a
>> &gt;&gt; directory not just in case of an FileAlreadyExistsException
>> but also in case
>> &gt;&gt; of an AccessDeniedException:
>> &gt;&gt;
>> &gt;&gt; private static void createAndCheckIsDirectory(Path dir,
>> &gt;&gt; FileAttribute<!--?-->&gt;... attrs)
>> &gt;&gt; throws IOException
>> &gt;&gt; {
>> &gt;&gt; try {
>> &gt;&gt; createDirectory(dir, attrs);
>> &gt;&gt; } catch (FileAlreadyExistsException x) {
>> &gt;&gt; if (!isDirectory(dir))
>> &gt;&gt; throw x;
>> &gt;&gt; + } catch (AccessDeniedException x) {
>> &gt;&gt; + if (!isDirectory(dir))
>> &gt;&gt; + throw x;
>> &gt; I am not sure that we want to hide the AccessDeniedException
>> when the target is
>> &gt; a directory. Subsequently executed code might encounter problems
>> and it could be
>> &gt; harder to identify the cause. Also, this code is used by all
>> platforms, not only
>> Linux.
>> &gt;&gt; }
>> &gt;&gt; }
>>
>> &gt;&gt; Some additional notes:
>> &gt;&gt; * A similar problem was reported and fixed in JDK-8032220
>> for MacOS and
>> &gt;&gt; Windows
>> &gt; In that issue, filtering of EISDIR was added but this appears to
>> be an error
>> specific to macOS.
>> What I was referring more to were the changes made in the
>> WindowsFileSystemProvider.createDirectory for JDK-8032220
>> (https://hg.openjdk.org/jdk9/jdk9/jdk/rev/8ff79b0e3503): An
>> ERROR_ACCESS_DENIED is catched and a FileAlreadyExistException is
>> thrown instead if the directory already exists.
>
> I see.
>
>> In the bug ticket (https://bugs.openjdk.org/browse/JDK-8032220) it is
>> said that "It does not appear to be an issue on Linux". This is true
>> for the special case of "/" handled in the bug ticket. But given the
>> behavior of mkdir regarding the return code according to Posix
>> similar problems could/do occur on Linux (as in my NFS case)
>
> To address your problem then the safest approach would appear to be
> overriding createDirectory() in LinuxFileSystemProvider to have the
> desired behavior, such as was done on Windows.
>
As a "user" of the API I would appreciate such a change.

Best regards,

Ole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20241129/10ea8f65/attachment-0001.htm>

From duke at openjdk.org  Sat Nov 30 22:37:41 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 30 Nov 2024 22:37:41 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: <m1VX5YRobPUBvO7KLiFAjRpWOzQxXU3TPArqJ5aAuXc=.fd12eeac-86d7-4d1c-8606-d104ea2154e2@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

Kindly asking to resume this suspended review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2509415760