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
