RFR: 8373630: r18_tls should not be modified on Windows AArch64 [v2]

[duke]

On Sat, 13 Dec 2025 05:09:33 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> On Windows, r18_tls is used to store the pointer to the current thread's TEB. Therefore, this register should never be modified (see details in [register_aarch64.hpp](https://github.com/openjdk/jdk/blob/23c39757ecdc834c631f98f4487cfea21c9b948b/src/hotspot/cpu/aarch64/register_aarch64.hpp#L118-L128)). One scenario that results in the modification of r18_tls involves virtual threads on Windows. Frames are frozen by [Continuation::try_preempt](https://github.com/openjdk/jdk/blob/23c39757ecdc834c631f98f4487cfea21c9b948b/src/hotspot/share/runtime/continuation.cpp#L131) on one carrier thread whose registers are saved. When the frame is thawed, execution can continue on a different carrier thread. When this happens, [rthread (x28) is fixed to point to the new carrier thread](https://github.com/openjdk/jdk/blob/23c39757ecdc834c631f98f4487cfea21c9b948b/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L2670). The continuation then results in [restore_live_registers](https://github.com/o
 penjdk/jdk/blob/23c39757ecdc834c631f98f4487cfea21c9b948b/src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp#L313) restoring all the saved registers (including the fixed rthread register). However, this also restores x18, which was the TEB pointer for the previous carrier thread, causing the new carrier thread to execute with the TLS of the previous carrier thread. This causes hangs and occasional crashes in the virtual threads jtreg tests on Windows AArch64 that are resolved by this fix.
>
> Saint Wesonga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not modify r18_tls if R18_RESERVED is defined

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

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

PR Comment: https://git.openjdk.org/jdk/pull/28808#issuecomment-3661162010