Re: tags in the 3 lowest bits

[Stefan Monnier]

>> Of course, an alternative would be to switch to BoehmGC.
> Sure, but is it a better alternative?  And why?

It would make array allocation much cheaper.  Now that's obviously not
consdered as an important part of the elisp engine since it hasn't been
optimized, so it can't be a main motivation for switching to BoehmGC.

> How does that remove the dependency on (non-aligned) mallocs?

BoehmGC does its own malloc, so it would solve it in the same way that
using emacs/src/gmalloc.c can solve it.

> I can understand your changes in the scope of the current GC scheme(s).
> Adding another one together with your changes doesn't seem necessary to me.

The two aren't linked indeed.

>> Dave Love has started work on this and it would be interesting to see
>> how it works out in practice (what kind of impact it has on memory
>> footprint and CPU usage).

> What is the status of that effort?  Dave?

> IMHO, this is not a user-visible change, so I think we have more
> important things to work on.

The BoehmGC is a pretty good package.  Its performance can be pretty good
and it can offer things like incremental collection which can make
a visible difference to the users.
Of course it does not always work great, it all depends on the actual
application and might require some tuning.

But if the performance is there, it would also have the advantage of saving
us from worrying about GC: we could scrap the GC code and rely on
a well-maintained piece of code.

Now, that doesn't mean that it should be a top-priority objective, but just
that working on it is not necessarily a waste of time.


        Stefan