Re: Tailcalls. Was Re: Manual timeslicing the VM.

[Glenn Maynard <glenn@...>]

On Fri, Aug 05, 2005 at 11:16:36AM -0500, Rici Lake wrote:
> As Mike points out, the phantom frames are not much use for
> debugging since they contain no information. It might even
> be argued that they hinder debugging, since programmers who
> are aware of tail-calls, and write their code accordingly,
> may not want to be distracted by the phantom frames, and may
> even find that they make it harder to access the information
> really desired (information about the real caller, for example.)

That makes some sort of sense for recursive tail calls, but if f tail
calls g, f is the real caller of g--if f was originally called by a,
I don't want debug calls telling me that g was called by a; it wasn't.  
Since it doesn't know anymore, I'd much rather have it say "don't know"
than to give a wrong answer (like C stack traces do).

> Even some C programmers count on tailcall optimisation: a change
> I proposed to Apache some time ago, which would have defeated a
> non-recursive tailcall optimisation, was rejected (amongst other
> reasons) because the tailcall optimisation in question "reduced
> noise on the debug backtrace". (I actually agree with that
> judgement, although I thought that the benefit outweighed the
> inconvenience.)

I hate when C backtraces are missing frames; it's extremely confusing
when there are several calls missing because of these optimizations.
Losing debuggability as a result of optimizations is usually an acceptable
tradeoff, of course, but it's definitely a trade, and I'm surprised that
some people actually *like* losing debug information in backtraces.

-- 
Glenn Maynard