Unexplained hangs on Windows arm64

[Fabian Meumertzheim]

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
<patricio.chilano.mateo at oracle.com> 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
>