On Thu, 22 Oct 2026 12:48:51 GMT, Ashay Rane <[email protected]> wrote:
>> This patch rewrites the code in the Windows port of HotSpot for detecting, >> handling, and reporting stack overflows. This patch is motivated by >> documented >> failures in JDK-8152598, JDK-8156538, JDK-8157521, JDK-8157924, JDK-8335362, >> and >> in JDK-8067946. >> >> The key result of this patch is that in addition to preventing the crashes >> that >> can be reproduced using the information in the above JBS issues, HotSpot on >> Windows now supports far-access stack bangs in compiled code while continuing >> to leverage Windows' incremental stack growth based on guard pages, ensuring >> that we don't sacrifice performance that would have been lost to page-by-page >> stack bangs. The Red and Yellow page counts now change the actual page >> permissions and HotSpot Guard Zone size, thus impacting the page that >> triggers >> the stack overflow error after stack banging. This patch also makes >> HotSpot's >> semantics for stack overflows for native and VM threads on Windows to match >> with >> those for Linux and macOS, in turn paving the way for supporting Reserved >> Stack >> pages on Windows. >> >> This is a non-trivial change, so I have documented the key ideas >> [here](https://gist.github.com/raneashay/82a0e2b32b3c051e92c5686bc0905743). >> The >> commits in this patch are organized (so far) to match the section headings in >> the document: >> >> - ed824007: [Section >> 4.1](https://cr.openjdk.org/~arane/windows-stack#growing-the-stack-on-demand) >> - f765e79d: [Section >> 4.2](https://cr.openjdk.org/~arane/windows-stack#matching-hotspots-guard-zone-with-windows-stack-guarantee) >> - 9d694f5c: [Section >> 4.3](https://cr.openjdk.org/~arane/windows-stack#handling-windows-stack-overflow-exceptions) >> - edf58c4f: [Section >> 4.4](https://cr.openjdk.org/~arane/windows-stack#handling-subsequent-stack-overflows) >> - ff9b65f6: [Section >> 4.5.1](https://cr.openjdk.org/~arane/windows-stack#miscellaneous-supporting-changes) >> - b3e146e9: [Section >> 4.5.2](https://cr.openjdk.org/~arane/windows-stack#miscellaneous-supporting-changes) >> - 8189a507: [Section >> 4.6](https://cr.openjdk.org/~arane/windows-stack#validation) >> >> I've validated this patch by running through all tier 1, 2, and 3 JDK, >> HotSpot, >> and LangTools tests on Windows/x64 and Windows/ARM64 in FastDebug config. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Ashay Rane has updated the pull request incrementally with one additional > commit since the last revision: > > Bringing back the change to `DEFAULT_STACK_SHADOW_PAGES` > > This makes Windows use the same number of stack shadow pages by default > as other OSes. In debugging a crash that happens without this patch, I learnt of a situation where the existing implementation can subtly corrupt memory. Sometimes this has more visible effects like the crash, but it's possible that the execution can silently continue with corrupted memory. Here's a reproduced paragraph from the document explaining the circumstances: > Crucially, unlike the existing upstream implementation, we do not use > `VirtualAlloc()` with `MEM_COMMIT` to commit pages, because doing so would > forego updating `StackLimit`, leading to situations where the stack pointer > ends up being _below_ `StackLimit`, which is an invariant failure by itself. > As the code continues executing, the implicit calls to `__chkstk()` in VM > code [write zeros into pages starting from > `StackLimit`](https://devblogs.microsoft.com/oldnewthing/20260319-00/?p=112152/), > thus overwriting used pages in the stack memory! This can lead to abrupt JVM > crashes because return address and local variables are now corrupted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32365#issuecomment-6367371713
