
Simon Marlow wrote:
Peter Hercek wrote:
The proposed meaning for :next
Lets mark dynamic stack size at a breakpoint (at which we issue :next) as breakStackSize and its selected expression as breakSpan. Then :next would single step till any of these is true: 1) current dynamic stack size is smaller than breakStackSize 2) current dynamic stack size is equal to breakStackSize and the current selected expression is not a subset of breakSpan
So what happens if the stack shrinks and then grows again between two breakpoints? Presumably :next wouldn't notice.
Yes, if there is no breakpoint in between I would not notice. I did not expect this can happen though. I thought that to add a frame on the stack this must be done within an expression (which is going to be forced) and the expression should be a breakpoint location. If it is so negligible that it does not have a breakpoint location associated then even the things it is calling should be negligible. Where is an error in this?
I think you'd be better off implementing this with a special stack frame, so that you can guarantee to notice when the current "context" has been exited.
This would be robust but I do not have knowledge to do it yet. If I understand you correctly this means that before executing a BCO which we are going to break at, we must prepare for a possible :next. So regardless whether :next is going to be issued by the user or not we would add a frame which represents a return to a function which: a) if user issued :next it enables all breakpoints so that we stop at the next breakpoint b) if user did not issue a break it would not do anything (just return) We could decide not to insert the frame when we are only tracing. But if I would want to track a simulated dynamic stack I would need to insert this stack frame at the start of each breakpoint (when dynamic stack tracing would be on). Does not sound that good.
I hope the above would make good sense but I do not really know since maybe rts does some funny things with stack sometimes. If you think the proposed behavior is garbage let me know why so that I do not waste more time with this :)
Yes the RTS does do "funny thing" with the stack sometimes. The stack can shrink as a result of adjacent update frames being coalesced ("stack squeezing").
OK, so it looks like either switching off the squeezing (if shrinking and growing stack between breakpoints/ticks is not such an issue), or inserting a stack frame. Does the "stack squeezing" happen during garbage collection? Thanks, Peter.