On Mon, 28 Sep 2026 00:44:49 GMT, Ashay Rane <[email protected]> wrote:
> Empirically, it looks like the address where we get EXCEPTION_STACK_OVERFLOW > is stack_low + guarantee + one page. I don't have a Windows machine to verify that, but according to the Wine source code, that sounds right. > So if/when we add the call to SetThreadStackGuarantee(), it looks like we > should probably set it to (yellow_page_count - 1) * page_size. I think it should match where HotSpot would do its first unguard, at the shadow --> reserved+yellow boundary. But as David pointed out, if we use SetThreadStackGuarantee(), we are mixing the Windows mechanism with the HotSpot mechanism. What I was hoping we could do was avoid EXCEPTION_STACK_OVERFLOW completely and only use EXCEPTION_ACCESS_VIOLATION. Please remind me again, what happens when we don't change SetThreadStackGuarantee(), so that that the end of the shadow zone (start of yellow+reserved) is outside of the Windows guarantee zone? According to Wine, there would be no EXCEPTION_STACK_OVERFLOW. Windows would move the guard page from the last shadow zone page to the first yellow/reserved page. But since these pages would still be PAGE_NOACCESS, when we resume and reexecute the trapped instruction, shouldn't we get a EXCEPTION_ACCESS_VIOLATION as desired? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32365#issuecomment-5883218509
