Currently ReservedStackTest runs with -XX:MaxInlineLevel=2 and
ReservedStackTestCompiler.java with -XX:-Inline. If larger inlining is allowed (-XX:MaxInlineLevel=4), these tests will fail.
Comments
Okay, thanks Dean. Let's close this.
14-06-2018
I'm OK with closing this.
[~thartmann] The current @run lines seem fine. We could have the test check the inlining settings at runtime, but I don't think it's critical to do so.
13-06-2018
Thanks for this detailed analysis, Frederic. If there are no objections, I think we can close this as Will-Not-Fix.
[~dlong], do we need to fix the tests to guard against other MaxInlineLevel settings?
13-06-2018
This is a known limitation of the way the reserved stack area is managed. There's a trade-off between improving protection against stack overflows in critical section and preserving inlining performance. The lock corruption the reserved stack area is trying to prevent is a rare bug (but it occurred both in tests and in the field), and preserving inlining performance. The problem is the cost of re-enabling the reserved stack area exactly at the end of the annotated section. The implementation allows the reserved area to remain disabled after the end of the annotated section, until the compilation unit returns, so the cost of the check is negligible when no stack overflow occurs. But it is true that if several stack overflows occur in the same compilation unit, there's a risk to observe the initial behavior and the lock corruption. The risk is very small in the field, because a single stack overflow on the critical section is rare, having two of them in the same compilation unit is even rarer. Unfortunately, the bug is very hard to reproduce, and in fact, the pattern the unit test is using to reproduce the bug is the most likely to expose the limitation, by trying to lock successively many locks in a tiny loop, which is a good candidate for in-lining.
The test is known to be brittle with respect to inlining, but so far, I haven't find a way to make it more robust.
I would recommend to close this bug a Will-Not-Fix, unless you have a better proposal.
12-06-2018
ILW = Reserved stack areas have no effect when inlining is not restricted, methods with @ReservedStackAccess annotation, no workaround = MMH = P3
11-06-2018
There seems to be a fundamental flaw in how reserved stacks are handled in the compilers. Unlike the interpreter, the compilers only check to re-enable the reserved stack when the parent method (compilation unit) returns. If we inline more than one call to a @ReservedStackAccess method, the 2nd and subsequent calls will not have reserved stack protection.