Re: Compiling Elisp to a native code with a GCC plugin

[Wojciech Meyer]

Tom Tromey <address@hidden> writes:

>>>>>> "Wojciech" == Wojciech Meyer <address@hidden> writes:
>
> Tom> It could be done.  It just requires someone willing to do the work.
>
> Wojciech> I know. I could get my old sources of generational garbage
> Wojciech> collector, to work. However it is a daunting job (the worse I
> Wojciech> could imagine, garbage collectors are nasty), plugging and
> Wojciech> debugging a new garbage collector to such huge and esoteric (I
> Wojciech> am sure people that who've been working on Emacs for years
> Wojciech> will not take this words badly and understand straight away
> Wojciech> what I am (a newbie) talking about) project like
> Wojciech> Emacs. However I might try to experiment with it (however
> Wojciech> unfortunately I am not that self confident about it ;) ).
>
> It is always ok to ask for help.

Thanks, I will keep in mind it.

>
> The current collector is very simple to understand.  If you read
> alloc.c, and look through the data structures representing lisp objects
> (in lisp.h), you will have a pretty good idea of what is going on.

It's open already :).

>
>
> FWIW, I looked at writing an incremental collector for Emacs.  I was
> primarily interested in using software write barriers... this turns out
> to be hard because there is a lot of code in Emacs of the form:
>
>    FIELD_ACCESSOR (object) = value;
>
> ... which for a software barrier has to be converted to:
>
>    SET_FIELD_ACCESSOR (object, value);

Yep, we would need barriers for the second heap. For young heap it is OK
to just scan it.

>
> (There are other bad things, too, like passing around a Lisp_Object*
> that points to the contents of a vector.)
>
> So, lots of grunge work, just to get the point where you could start
> actually working on the GC.  I would look at automated rewriting to
> make this work -- that worked out great on the concurrent branch.

Maybe that work should be actually done even without thinking currently
about GC. AFAIR MT Emacs rewriting was in Elisp, ideally maybe using GCC
would be better at some point.

>
>
> There was a more real attempt based on the Boehm GC.  I think the bits
> from that are still on a branch.  This GC has a generational mode that,
> IIRC, is based on memory protection bits.
>

Conservative Boehm will not bring much gain (I would think certainly
loss) of performance. However I didn't know about marking pointers based
on memory protection bits and that sounds interesting. Need to look at
it. (however I am fully convinced that custom GC would be a superior
option).

> Tom

Wojciech