Hi Patricio, thank you for the pointer!
I verified that the hang is fixed with the latest JDK 27 EA. I haven't found an EA build of 25.0.3+1 yet, but I will try to build my own and validate that the issue is fixed. Fabian On Fri, Feb 6, 2026 at 3:56 AM Patricio Chilano Mateo <[email protected]> wrote: > > 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 >
