Stack check for AP_STACK
|Reported by:||simonmar||Owned by:||simonmar|
|Type of failure:||None/Unknown||Difficulty:||Moderate (less than a day)|
|Test Case:||concprog001||Blocked By:||#4258|
This is a bug I uncovered in the interpreter, that I think is also present in the compiler.
When compiling code for a function or thunk, we aggregate the stack usage from case continuations up to the top of the function/thunk and perform a single stack check. This normally works fine: we know the maximum amount of stack that will be required in the evaluation of this function/thunk, and we check for it up front.
However, this goes wrong if the evaluation is suspended by an asynchronous exception: the stack is broken into chunks and stored in AP_STACK objects, which may later be resumed. On resumption, we might not have enough stack any more: the code might now be running on another stack entirely, even.
Our proposed solution is as follows:
- Continuations that require more than a certain amount of stack (say 4k) do their own stack checks.
- an AP_STACK object records the amount of stack available at the time it was suspended, if the amount is <4k. On resumption of an AP_STACK, we ensure that at least this amount of stack is available. (there's a spare half-word field in AP_STACK that we can use for this).
The 4k limit is important: it puts a bound on the amount of stack growth due to evaluating an AP_STACK. Essentially the 4k limit is large enough that it almost never happens.
Change History (14)
comment:6 Changed 5 years ago by simonmar
- Component changed from Runtime System to Compiler
- Milestone changed from 6.12.1 to 6.14.1
comment:7 Changed 4 years ago by simonmar
- Difficulty changed from Moderate (1 day) to Moderate (less than a day)
comment:11 Changed 3 years ago by igloo
- Milestone changed from 7.2.1 to 7.6.1
- Type of failure set to None/Unknown