On Sat, 26 Sep 2026 07:39:14 GMT, Dean Long <[email protected]> wrote:
> Doesn't this happen because the page is in the range set by > SetThreadStackGuarantee()? I removed the calls to `SetThreadStackGuarantee()` in the last few commits, with the goal of getting the exception handling nailed down first. So the current patch has no calls to `SetThreadStackGuarantee()`. > I'm wondering what happens if we instead set SetThreadStackGuarantee() to the > smallest size possible (1 page?). Will we then get a > EXCEPTION_ACCESS_VIOLATION instead of EXCEPTION_STACK_OVERFLOW? My observation so far is that calling `SetThreadStackGuarantee()` is effectively a NOP (in terms of observable exceptions) until we pass 12KB or more as its argument (assuming the yellow page count is still set to 3 on Windows). At 12KB and higher, Windows raises `EXCEPTION_STACK_OVERFLOW` even when the access is above the yellow zone (i.e. in the usable portion of the stack). Empirically, it looks like the address where we get `EXCEPTION_STACK_OVERFLOW` is stack_low + guarantee + one page. So if/when we add the call to `SetThreadStackGuarantee()`, it looks like we should probably set it to (yellow_page_count - 1) * page_size. > > ```c++ > > // Java_java_net_SocketOutputStream_socketWrite0() uses a 64k buffer on the > > // stack if compiled for unix and LP64. > > ``` > > That comment looks to be seriously out of date. Current code doesn't seem to > use an on-stack buffer. Thanks for catching that! It looks like `Java_java_net_SocketOutputStream_socketWrite0()` no longer exists, so I've removed the reference in the comment. --- I came across a previously-unhandled case that could arise when we end up performing a page-by-page probe (something like `_chkstk()` in native code), which results in `EXCEPTION_STACK_OVERFLOW` while the yellow+reserved zones are un-guarded due to an `EXCEPTION_ACCESS_VIOLATION`. This is unlikely to be something that we encounter routinely (indeed, none of the HotSpot tests exercise this case) but out of caution, I've added the code to just retry the instruction. Since the yellow and reserved zones are un-guarded (i.e. marked as `PAGE_READWRITE`), we expect the retried instruction to succeed, but if it reaches the red zone, we'll handle it as an unrecoverable overflow. I am bit on a shaky foundation about this edge case, so if you have suggestions for whether/how we should handle this case, please let me know. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/32365#issuecomment-5861375980
