[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Tailcalls. Was Re: Manual timeslicing the VM.
- From: Glenn Maynard <glenn@...>
- Date: Fri, 5 Aug 2005 12:47:24 -0400
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
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.