Re: C-h f now permanently loads ~2MB

[Dave Love]

Stefan Monnier <address@hidden> writes:

> Well, we could use posix_memalign for that indeed.

?? memalign isn't in POSIX.  I think it's a SunOS invention that's
also in Irix, but not in Tru64, for instance.  However, it does what
you want, and you'd have to know individual mallocs' behaviour was
guaranteed otherwise.

> But glibc's malloc, Mac OS X's malloc, gnumalloc (as distributed with
> Emacs) and many more already guarantee a multiple-of-8.
> It is not portable, tho, because the only guarantee we have (from the
> C standard) is that malloc returns something aligned on the
> maximum-alignment-requirement of basic types (which is 8 on many RISC
> systems for the `double' type, but is 4 on x86).

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.)

> Well you didn't advertise it very well either

I discussed it with rms beforehand and posted to emacs-devel.  What
else should I have done?

> Does the incremental and/or generational GC work?

Yes (assuming you have the barrier support for generations).

> 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.  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.  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/>

> I think if the performance is right (CPU- and memory-wise), we should move
> in this direction, but I know there many difficulties (compatibility for
> oddball systems

I don't know of any that Emacs currently runs on that the GC doesn't
support.  I don't think there's a big portability problem if you don't
care about threads and data in shared libraries.

> and legal paperwork spring to mind.  But since GCC uses it, I expect
> those difficulties are very surmountable).

rms said OK long ago.

> 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.]