On 12/27/10 8:15 PM, Stefan Monnier wrote:
>> Hrm. You learn something every day --- I thought Emacs was doing precise
>> GC the way it has since time immemorial.  How much of a win was the
>> GC_MARK_STACK conservative scanning approach?
> 
> As long as we still support platforms that use GCPROs, it's not a win
> at all.  Tho it may have beneficial effects on the performance, I don't
> know (it could also be detrimental to performance, by the way, because
> of extra work it has to do every time we allocate memory for Lisp
> objects in order to later on be able to conservatively tell whether an
> integer happens to point to an allocated memory area).
> 
> 
>         Stefan

Of course, since insertion in a RB tree is O(log N), N here being the
number of allocated memory blocks, my gut tells me that consing time
isn't hurt all that much. The whole approach basically moves work from
the whole runtime (in the form of GCPRO) to allocation and deallocation.
I don't know whether that's a win.

Why bother with the conservative scanning at all? If it's on by default
almost everywhere, then it might be hiding the presence of GCPRO bugs.
Conservative scanning seems more useful as a debugging aide
(GC_MARK_STACK_CHECK_GCPROS and CHECK_ZOMBIES) than as the primary GC
strategy.

Usually, conservative GC is what you do when there's not enough
information for precise GC, but that's not the case in the Emacs core.

Has anyone run benchmarks lately? Eight years is a long time.