for opal compiler developer: issue on calculating the frameSize
I uploaded a cs fix_closure_stack_frame_size_computation for this issue 13854 <https://pharo.fogbugz.com/default.asp?13854> frameSize calculated wrongly for #lineSegmentsDo: ! It is not meant as a fix but to show and make it easier to understand where the bug is. I don't like this fix because it looks like "fixing the right bug at the wrong place" About the issue: It is all about calculating the correct stack frame size for a compiled method (compiledmethod>>#header) With opal, the result is sometimes larger than it is needed or to small (strangly enough, although we have *some* methods with a too small stack frame, a vm crash only happens for me if I am stepping through the method with the debugger). The needed stack frame size is calculated from the numTemps (arguments + number of temporaries) + the max stack depth *and* if the method defines any blocks the methods stack frame size is the maximum of - its own needed stack frame size - all of its blocks needed stack frame sizes. (And what makes this calculation a little bit tricky, the methods arguments and tempvars, although it looks like that, don't influence the stack frame size for the blocks. Every block context starts with its own stack) nicolai
Thanks Nicolai. I imagine that clement/marcus will have a look. I have been recently running too much. Stef Le 29/11/14 11:14, Nicolai Hess a écrit :
I uploaded a cs fix_closure_stack_frame_size_computation for this issue 13854 <https://pharo.fogbugz.com/default.asp?13854> frameSize calculated wrongly for #lineSegmentsDo: !
It is not meant as a fix but to show and make it easier to understand where the bug is. I don't like this fix because it looks like "fixing the right bug at the wrong place"
About the issue: It is all about calculating the correct stack frame size for a compiled method (compiledmethod>>#header) With opal, the result is sometimes larger than it is needed or to small (strangly enough, although we have *some* methods with a too small stack frame, a vm crash only happens for me if I am stepping through the method with the debugger).
The needed stack frame size is calculated from the numTemps (arguments + number of temporaries) + the max stack depth *and* if the method defines any blocks the methods stack frame size is the maximum of - its own needed stack frame size - all of its blocks needed stack frame sizes.
(And what makes this calculation a little bit tricky, the methods arguments and tempvars, although it looks like that, don't influence the stack frame size for the blocks. Every block context starts with its own stack)
nicolai
I will have a look later this weekâ¦
On 29 Nov 2014, at 11:14, Nicolai Hess <nicolaihess@web.de> wrote:
I uploaded a cs fix_closure_stack_frame_size_computation for this issue 13854 <https://pharo.fogbugz.com/default.asp?13854> frameSize calculated wrongly for #lineSegmentsDo: !
It is not meant as a fix but to show and make it easier to understand where the bug is. I don't like this fix because it looks like "fixing the right bug at the wrong place"
About the issue: It is all about calculating the correct stack frame size for a compiled method (compiledmethod>>#header) With opal, the result is sometimes larger than it is needed or to small (strangly enough, although we have *some* methods with a too small stack frame, a vm crash only happens for me if I am stepping through the method with the debugger).
The needed stack frame size is calculated from the numTemps (arguments + number of temporaries) + the max stack depth *and* if the method defines any blocks the methods stack frame size is the maximum of - its own needed stack frame size - all of its blocks needed stack frame sizes.
(And what makes this calculation a little bit tricky, the methods arguments and tempvars, although it looks like that, don't influence the stack frame size for the blocks. Every block context starts with its own stack)
nicolai
participants (3)
-
Marcus Denker -
Nicolai Hess -
stepharo