Re: Finding objects on C stack - alternate GCPRO

[Stefan Monnier]

> Everyone agrees that GGPROs are ugly and painful. On the other side,
> current C stack marking code introduces substantial overhead by
> maintaining red-black tree.

I don't think the red-black-tree is a big overhead, in general.
The only place where it is significant is when (de)allocating small
vectors, which we could solve by using a special allocator for
small vectors.

> And, since C stack marking is conservative, it becomes very tricky to
> implement GC that may relocate live objects (copying or compacting
> approach).

Making all objects relocatable would require not only "precise marking"
but also "exhaustive marking" which is currently not the case.
Given the bugs we bump into already for string relocation I'd expect
that making all objects relocatable would make for a lot of nasty
debugging unless we can get GC info to be exhaustive (including
C pointers into Elisp objects) in a fully automated way (i.e. without
any manual annotation, be it GCPRO or FOOPTR).

> But there is another method to implement GCPROs. It looks not very
> portable beyond GNU C since it uses __attribute__ ((cleanup (function)))
> and compound statement expressions C extensions. But it doesn't
> require UNGCPRO and dumbs like 'struct gcpro gcpro1, struct gcpro2, ...'.
> And I believe it should work across longjmps.

Interesting.  You'd need to adjust your macro so as to make sure that
the Lisp_Object variables are initialized before they're added to the
gcpro list, but otherwise it's indeed cleaner than our current macros.
On the performance side, it could be slower depending on how aggressively
gcc optimizes alloca and foo_remove calls and more importantly depending
on whether it handles longjmp for us (which would be less efficient,
tho I don't know if that would be significant).

> This idea is briefly illustrated by an attached example. As for the
> Emacs, it would be enough to declare every local Lisp_Object which
> should survive the GC with the stuff like FOOPTR from this example,
> and we're ready for exact C stack marking with (hopefully) very small
> overhead.

The problem is that the few platforms that don't use GCC are the ones
that require GCPROs as well, so not only it would be a large change, but
it would also require us dropping support for those non-gcc
non-conservative-GC platforms.

I guess this would only make sense if we decide to use this FOOPTR in
preference to conservative stack scanning.  But as it stands, I don't
see it happening, unless we have some compelling reason to do it
(e.g. benchmark showing there's a significant gain, or actual new
feature/code to take advantage of the extra gcpro info).


        Stefan