pepe wrote:
Having (a kind of messy approximation of) a dynamic stack is possible
with a variant of the cost center stacks mechanism used for profiling.
But the downside is that code and libraries would need to be compiled
for debugging.
Is there any info somewhere why the approximation of the dynamic stack
needs libraries to be recompiled for debugging? I thought about it but I
could not figure out why it would be needed. Here is what I thought is
the way it works:
* the ticks only inform about the approximate start of the selected
expression; this is acceptable provided it makes it much easier to implement
* the number of items (continuations) on the return stack from the
beginning of /case tick<n> of {_->e}/ to the moment when we can check
the count of items in the return stack inside /tick<n>/ is constant and
known for a given runtime version of ghc
Provided the above is true then we can find out the number of items on
the return stack which was valid just before /case tick<n> of {_->e}/
was entered. Lets mark this number as tick_stack_size<n>. Then the only
thing we need to build the approximation of the dynamic stack is to get
a callback from the runtime just before the number of items in the
return stack gets below tick_stack_size<n> for the corresponding /case
tick<n> of {_->e}/ expression. That is the moment of "step out" from the
selected expression and that is the moment when we can pop an item from
our dynamic stack approximation. (Each entering of /tick<n>/ pushes one
item to the dynamic stack approximation.)
All the requirements to implement the above way seem to be easy to do
and they do not look like having too bad speed consequences. Just one
indirect memory access and a conditional jump more for each pop of a
continuation address from the return stack. And the most important thing
is that it does not matter whether a library you use is "strobed" with
ticks or not. If a library is not "strobed" it would just look like one
item in the approximation of the dynamic stack. If a library is not
interpreted (it is not being debugged) we do not want to be bugged with
its stack frames anyway ... probably. It looks to me better this way
without any experience with it yet. Some of the conditional jumps would
happen and would result in more work (maintaining the approximation of
the dynamic stack), but all non-tagged value accesses would not as well
as all expressions which are not annotated with ticks (like e.g. list
creation).
Anyway, since the libs would be needed to be compiled for debugging
something in the above is wrong. I would like to know what is wrong or
some pointer to some web page or paper which describes how the
approximation of the dynamic stack works for profiler. I cannot think of
other way the profiler dynamic stack approximation would work :-/
Thanks,
Peter.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
