On Mon, 28 Sep 2026 00:48:39 GMT, Ashay Rane <[email protected]> wrote:
>> Prior to this patch, the `StackYellowPages` and `StackRedPages` >> influenced the total reserved stack memory, but they didn't change the >> minimum stack size specified as required by HotSpot to Windows. This >> patch adds the call to `SetThreadStackGuarantee()` to set the minimum >> stack size. >> >> The key change here is that the argument to `SetThreadStackGuarantee()` >> is set to one less than the total number of yellow pages. The one less >> page is because Windows uses a guard page (access to which tells Windows >> to commit more stack pages); in the terminal case, we want the guard >> page to coincide with the top-most yellow stack page, thus leaving all >> except one yellow page available as the stack size. >> >> Importantly, however, we do not use the red page count as the argument >> to `SetThreadStackGurantee()`, since the red stack pages are unavailable >> for handling recoverable overflows. The red page count impacts the >> _total reserved_ stack size, just not the _minimum_ stack size. Still, >> forcing the red stack page count to be included into the computation of >> the argument to `SetThreadStackGurantee()` causes HotSpot to fail with >> the assertion `assert(!in_vm) failed: Undersized StackShadowPages`, >> since Windows is unable to commit more stack pages due to the minimum >> stack size now being larger than just the yellow page count minus one. >> >> The accompanying test passes zero to `SetThreadStackGuarantee()` to >> probe the current minimum stack size, which we then compare against the >> expected size based on the yellow page count. The same test fails >> without this patch on both Windows/x64 and on Windows/ARM64. >> >> Validated this patch by running through all tier 1, 2, and 3 HotSpot >> jtreg 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: > > Handle EXCEPTION_STACK_OVERFLOW when yellow zone is unguarded > > The previous code did not handle a corner case that arises when HotSpot > receives `EXCEPTION_STACK_OVERFLOW` (since the guard page cannot be > moved further down) while already processing a recoverable overflow. In > this case, the yellow and reserved zones are writable (as part of the > recoverable overflow), so we retry the same instruction. If the > faulting probe reaches the red zone, we'll receive > `EXCEPTION_ACCESS_VIOLATION`, which will be handled as an unrecoverable > overflow. Sorry about the misunderstanding. Did you mean something like this? - `DEFAULT_STACK_RED_PAGES` set to 3 (I also tried with 4 to account for the guard page) - EXCEPTION_STACK_OVERFLOW => unrecoverable overflow - EXCEPTION_ACCESS_VIOLATION and yellow zone address => recoverable overflow - EXCEPTION_ACCESS_VIOLATION and red zone address => unrecoverable overflow - SetThreadStackGuarantee(8KB) If that's correct, the problem is that tests like StressStackOverflow.java, Frames2Test.java, and TestStackOverflowDuringInit.java fail with errors like: # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x00000263d757b2a0, pid=70932, tid=65444 # # JRE version: OpenJDK Runtime Environment (28.0) (fastdebug build 28-ea+0-adhoc.spur) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 28-ea, mixed mode, sharing, tiered, compressed oops, compact obj headers, g1 gc, windows-amd64) # Problematic frame: # J 74 c1 StressStackOverflow.fibonacci_pad1(ILjava/lang/Runnable;)J (34 bytes) @ 0x00000263d757b2a0 [0x00000263d757b280+0x0000000000000020] My guess is that the stack bang ended up in the highest yellow page, but since the yellow pages are committed, there's no room to grow the stack any more, causing Windows to raise an `EXCEPTION_STACK_OVERFLOW`, resulting in the error message. I thought about leaving the yellow pages uncommitted (i.e. at `MEM_RESERVE`) but I don't think we can apply `PAGE_NOACCESS` to pages that aren't committed yet. Apologies if I misunderstood your message. In any case, I'll wait until you get a chance to run your experiments. In the meantime, if I come across something new that's relevant, I'll post here again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32365#issuecomment-5903603877
