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

[Stefan Monnier]

>> It assumes that malloc returns multiple-of-8 addresses and thus
>> allows the full address space to be used for Lisp data.
> Surely you need `memalign' for that?  (Non-portable, but in GNU
> malloc.)

Well, we could use posix_memalign for that indeed.
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).

>>> The Boehm GC give you some tools to trace memory allocation and
>>> pointers keeping data live when they shouldn't, but I don't know how
>>> easy they are is to use.
>> Sounds very interesting.
> It didn't seem to sound interesting to anyone when I advertised the
> work :-(.

Well you didn't advertise it very well either and it sadly came right when
I was making incompatible changes to the alloc.c code
(i.e. mostly removing markbits).

Does the incremental and/or generational GC work?
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 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 and legal paperwork spring to mind.  But since GCC uses it,
I expect those difficulties are very surmountable).

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


        Stefan