[jdk21u-dev] RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

[Severin Gehwolf]

On Thu, 8 Feb 2024 11:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is a series of Loom backports that brings in the fixes from JDK 22 and mainline into JDK 21, where Loom is production-ready. This batch fixes a few thread state and JVMTI problems.
> 
> Unfortunately, these backports are tied together, as they change the same code a few times. It is very hard to make them into separate backports without breaking stuff along the way, so instead I clobbered them together in this PR. They follow the application order from mainline. All patches together touch only the Virtual Thread parts, so the risk for the rest of the code should be minimal.
> 
> Brief explanation of fixes:
> 
> * [JDK-8315373](https://bugs.openjdk.org/browse/JDK-8315373): In mainline since Sep 2023, there is no bug tail. Changes how VTs interact with JVMTI. We want this fix to provide the ground for the rest of backports. Notably, it makes [JDK-8312777](https://bugs.openjdk.org/browse/JDK-8312777) backport clean. 
> * [JDK-8312498](https://bugs.openjdk.org/browse/JDK-8312498): In mainline since Sep 2023. There is a bug tail, [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818). Fixes what thread state VT reports when timed-parked. This fixes the actual Loom bug.
> * [JDK-8312777](https://bugs.openjdk.org/browse/JDK-8312777): In mainline since Oct 2023, there is no bug tail. Fixes the JVMTI race with mount/unmount events. Makes [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818) backport clean. This fixes the actual Loom bug.
> * [JDK-8321270](https://bugs.openjdk.org/browse/JDK-8321270): In mainline since Dec 2023, there is no bug tail. Makes [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818) a clean backport. This fixes the actual Loom performance problem.
> * [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818): In mainline since Jan 2023. Fixes the bug introduced by [JDK-8312498](https://bugs.openjdk.org/browse/JDK-8312498). Has two additional follow-ups: [JDK-8323002](https://bugs.openjdk.org/browse/JDK-8323002) and [JDK-8323296](https://bugs.openjdk.org/browse/JDK-8323296).
> * [JDK-8323002](https://bugs.openjdk.org/browse/JDK-8323002): In mainline since Jan 2023. Follow-up test fix for [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818). Test-only change.
> * [JDK-8323296](https://bugs.openjdk.org/browse/JDK-8323296): In mainline since Jan 2023. Follow-up test fix for [JDK-8322818](https://bugs.openjdk.org/browse/JDK-8322818). Test-only change.
> * [JDK-8316924](https://bugs.openjdk.org/browse/JDK-8316924): In mainline since Sep 2023. Fo...

Yes, integrating it sooner rather than later would be preferred. Ramp down starts next week for JDK 21.0.3. It's not a low risk change. Having said that, I concur it's fairly well isolated to loom code and there were no objections in principle from other maintainers. We'll have to see and if worse comes to worst we'll back it out before April.

So in a nutshell, the question was whether to allow for 21.0.3 or push to 21.0.4. It'll have about 2 months before the release in April (21.0.3). If it was pushed to 21.0.4 we'd have some more testing in the `jdk21u-dev` tree, but to me the first merge to `jdk21u` matters. Going by that, we'd have similarly about 2 months of testing with public EA builds. So the characteristics don't change much. Therefore, approved for `21.0.3`.

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

PR Comment: https://git.openjdk.org/jdk21u-dev/pull/245#issuecomment-1952453104