GC (was: C-h f now permanently loads ~2MB)

[Stefan Monnier]

>> Well, we could use posix_memalign for that indeed.
> ?? memalign isn't in POSIX.

Indeed, but posix_memalign is (in the realtime part of it).

http://www.opengroup.org/onlinepubs/009695399/functions/posix_memalign.html

> Exactly.  Using dlmalloc generally would give you memalign anyway, and
> is known to work on Solaris -- the only significant platform that
> apparently requires one of the system mallocs.  (I'd actually expect
> most architectures to malloc on 8-bit boundaries because you took a
> performance hit with unaligned doubles even on VAX -- let alone
> Pentium -- but there are several architectures I don't know about
> without grovelling gcc source.)

Currently, I don't know of any way to get USE_LSB_TAG to work on "any
machine" because it not only require a malloc that allocates on
multiple-of-8 boundaries, but it also needs multiple-of-8 allocation of
a few static pieces of data (all Lisp_Subr which are not a serious problem
since I can align them manually, and the two special static pseudo-buffers
buffer_defaults and buffer_local_symbols: the second one is not very
important so I we can handle it slowly but the first one seemed more tricky
to deal with without a potentially noticeable performance penalty).
I only know how to specify alignment of static data on GCC, so USE_LSB_TAG
currently only works with GCC.

>> Well you didn't advertise it very well either
> I discussed it with rms beforehand

Doesn't help me 'cause I don't have access to Richard's
private conversations.

> and posted to emacs-devel.
> What else should I have done?

Don't know.  Flap your arms, quack, ... something? ;-)

>> Does the incremental and/or generational GC work?
> Yes (assuming you have the barrier support for generations).

Cool.

>> What does the performance look like?  I expect it is a lot faster for
>> arrays (our array allocation code is pretty dreadful right now), but what
>> about the rest?

> I didn't measure it in Emacs since I didn't get it working properly,
> as I said in the post about it.

That's not a great advertisement, now is it?
I understand how you feel, but the patch is pretty large and is non-working,
so it takes a fair bit of effort for anyone to come and help you.

> Since there was obviously no interest, I never revisited what I was
> missing to get it sorted out.  I think Boehm has performance figures on
> his web site.  It would be surprising if it didn't perform at least as
> well as the Emacs gc, especially for collections with large working sets.

That's what I would expect as well, but since Emacs's current GC is only
conservative w.r.t. stack scanning and has distinct allocation methods for
various types of data, Boehm's GC is likely to have a different "performance
envelope".

> You could run a Gabriel benchmark in, say, mzscheme and Emacs, but I think
> mzscheme has larger conses than Emacs.
> <URL:http://www.hpl.hp.com/personal/Hans_Boehm/gc/>

Those two systems are pretty radically different in many ways, so I'm not
sure how relevant the comparison would be.  I know that Boehm's GC is
generally considered "good enough" and our current GC is no speed deamon,
so I already know that it should theoretically be possible to get good
performance with it.  What is still missing is concrete data about our
particular case.

>> I just glanced at your branch and was wondering: what's the difference
>> between xmalloc and XGC_MALLOC (i.e. when should one be used rather than
>> the other)?

> I don't remember and I don't have the code now.  XGC_MALLOC was
> probably for storage containing Lisp objects which was previously just
> malloced -- stuff with special mark/sweep procedures previously.

> [Note that if you can use low-order tags so that you can allocate with
> mmap, as Boehm GC prefers, it may be straightforward to dump the heap
> that way rather than having unexec break continually.]

Right, with USE_LSB_TAG several things might have to be done differently
(the off-by-one trick for marker chains springs to mind).
So I'm interested in knowing why you did things the way you did to know
what changes might be needed, what simplifications could be made.


        Stefan