Re: Tooltips GC overhead

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: Stefan Monnier <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Fri, 07 Aug 2015 17:25:37 -0400
>> 
>> >> I'd welcome a patch which uses such a "sampling watchpoint", since it
>> >> would even speed up the code by removing the code that counts calls
>> >> to malloc.
>> > Sorry, your jokes are beyond me.
>> 
>> You must have misunderstood, because that was no joke at all.  I really
>> mean it: I'd be happy to see a patch which uses the same trick used by
>> GDB to add a "watchpoint".
>
> GDB uses debug registers and the debug interface that catches the
> resulting signal/exception, something a well-behaving program that is
> not a debugger should never do.

Well, but in this case we want to debug a problem.  So it might be worth
considering how to make it easy and/or standard to generate/retrieve the
desired information from a debugger.  Interpreted languages like
GUILE/Elisp tend to be a real mess to debug regarding the setting of
break points and trapping on virtual machine registers and so on.  The
question is how one could make it easier to immerse the debugger in the
world view of an interpreted/VM application and use its hardware tools
for debugging problems not cast in terms of actual assembly code on the
executing CPU.

Zero-expense Lisp-level hooks that only become available within a
debugging session (and of course have quite non-zero cost when activated
but zero when not) but do not require recompilation would fall in that
class.

Of course, that would be a nice long-term solution.  But the mere
potential for a long-term solution does not solve short-term problems.
In particular if nobody is working on the long-term solutions.

-- 
David Kastrup