It looks like the EPoll bug on windows is widely reported, but there also is a fair amount of critique of epoll in general. This article goes into depth on triggering events and various issues. My understanding though is that windows doesn’t even have a true epoll, on a layer over the native kernel event system. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/
> On Feb 11, 2026, at 10:27 AM, Alan Bateman <[email protected]> wrote: > > On 11/02/2026 16:00, Matthew Swift wrote: >> Hi, >> >> I suspect that I've discovered a bug in the IO polling mechanism used by >> virtual threads on Windows. I've been able to systematically reproduce the >> problem on Windows 2016, 2019 and 2022 Intel x64 using both JDK 25.0.2 and >> 25.0.3 EA build 01, and also JDK 27 EA 8 build. The problem occurs when the >> server attempts to send a large response message to the client. The server's >> write operation becomes blocked and is never notified when the socket >> becomes writable again: > > Can you determine if a blocking read outstanding on the same connection that > another thread is blocked on the large write? Can you set SO_SNDBUF to a > large value to see if that reduces or eliminates the sightings? > > We have been chasing an issue in the Windows Ancillary Function Driver for > winsock that arises when a Windows SOCKET is use with two different > completion ports or AFD device handles at the same time. Daniel Jeliński has > some good analysis here: > https://github.com/piscisaureus/wepoll/issues/35 > > We have a prototype poller implementation that works around this issue but it > has some performance impact (on Windows) so have been slow to process it [1]. > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8334574 > >
