Unexplained hangs on Windows arm64

[Patricio Chilano Mateo]

Hi Fabian,

This is likely due to https://bugs.openjdk.org/browse/JDK-8373630. I see 
you are testing on 25.0.2 but the fix is in 25.0.3. Could you see if it 
reproduces with a newer build?

Patricio

On 2/5/26 6:40 PM, Fabian Meumertzheim wrote:
> Hi everyone,
>
> I'm currently investigating indefinite hangs of the build system Bazel 
> that occur only on Windows arm64 
> (https://github.com/bazelbuild/bazel/issues/28520) - Linux, macOS as 
> well as Windows x64 are unaffected. Bazel runs itself via an embedded 
> JDK 25 and I've been able to reproduce the same hangs on 25.0.2.
>
> The hangs occur while Bazel downloads external dependencies using 
> HttpURLConnection in virtual threads created by a 
> VirtualThreadPerTaskExecutor. I captured JSON thread dumps 
> (https://github.com/user-attachments/files/25097968/threads.json and 
> https://github.com/user-attachments/files/25102540/threads2.json are 
> examples, but I can provide more) which all seem to have the following 
> in common:
> 1. Virtual threads are blocked in either very short synchronized 
> blocks (e.g. SynchronizedMap methods) or WEPoll#ctl.
> 2. There are enough carrier threads available throughout (the machine 
> has 8 cores).
>
> I don't know how to explain why there is no progress in these 
> situations - the thread dumps don't seem to point to an obvious 
> deadlock, but the program never makes progress again after getting 
> into this state. WEPoll#ctl led me to think that this may be related 
> to a subtle deadlock issue affecting the Go runtime 
> (https://www.ntkernel.com/a-rare-cancelioex-hang-in-go-on-windows/), 
> but I then found thread dumps such as the second one above that don't 
> include an such frames.
>
> Is there anything special about the Loom impl on Windows arm64 that 
> could explain this behavior?
>
> Fabian