strange behavior with stack overflow on windows

[Roland Westrelin]

Runtime folks,

I'm investigating:
JDK-8015660 Test8009761.java "Failed: init recursive calls: 24. After deopt 25"
and I see a strange behavior on windows.

The test case calls an interpreted method recursively until a stack overflow and counts the number of invocations. Then it forces a compilation and a deoptimization. The test's goal is to check that a deoptimization rebuilds the interpreter frames correctly when there's one inlinee. It wasn't the case on sparc. So the test calls the interpreted method recursively again until a stack overflow and counts the number of invocations again.

It then checks the before and after counts and they should be the same. On windows (x64 at least), they are not the same. They differ by one, the second one being greater by one.

I looked at the stack layout and the faulting address and what I see is that the first access violation is triggered by an address in the page right above the yellow zone. For instance: stack guards are 3 pages from 0xdc20000 and the exception happens at 0xdc232a8. The second violation occurs in the yellow zone. If I add a third overflow to the test, then it happens in the yellow zone as well.

Is it a known issue?

I looked at the code and it looks like windows uses guard pages that are disabled on first violation. So maybe the windows thread creation code adds a page guard at the last page of the stack on thread creation but it's hard to tell from the documentation. I didn't find anything wrong in the hotspot code.

Does it look like a bug that's worth fixing?

Otherwise, I can change my test so that it triggers 3 overflows and only keep the invocation counts for the last 2.

Roland.