Re: Forthcoming revisions to the garbage collector; crazy huge hack
On Mon, 21 May 2001, Ovidiu Predescu said:
This sounds like a really fun project!
Absolutely. I like cleaning up ugly cruft, and the XEmacs GC layer is
really rather in need of a good clean, encrufted by sheer age.
[typed memory]
It turns out however that describing memory layout however is not an
easy task. Different machines have different memory layouts and
getting this right is very machine dependent. Currently the piece of
code that determines the memory layout (which in turn is used to
describe the typed memory for Boehm's GC) is the most problematic and
causes the most headaches in the GNU Objective-C runtime library.
I plan to try out the _EXPLICITLY_TYPED() stuff, but it would indeed be
a nightmare to implement portably, even with heavy use of offsetof().
I agree with Hans when he said in gc_typed.h
* Should be used only for extremely performance critical applications,
* or if conservative collector leakage is otherwise a problem (unlikely).
... so I plan to let XEmacs run for a while both with and without heavy
use (nonportably implemented, quickly hacked up ;) ) of typed memory and
compare their memory hits. I doubt it'll have all that much of an
impact, because most of XEmacs's data structures are either stuffed with
pointers, or totally devoid of them. What'll really have an impact is
using GC_MALLOC_ATOMIC() in the right places.
(Thank goodness for the objectified nature of XEmacs's memory allocation
code!)
Just a word of caution if you decide to use typed memory. You may
want
to take a look at the GCC code in the Objective-C runtime library, to
see how things are done. Checkout gc.c and encoding.c in the libobjc
directory:
The method you use there (__objc_generate_gc_type_description() and
friends) depends intimately on a description of the layout of the type
being provided by the compiler. Of course, this is practical for
libobjc; but I rather doubt that I can convince the SC that a `Typed GNU
C' extension is wise when offsetof() will do the same job :)
(And, in any case, XEmacs has to build with non-GCC compilers,
distasteful though the thought is ;) )
Myself, I'm still slightly worried about what this will do to the weird
old architectures XEmacs presumably still builds on. I guess if anyone
complains about any of them the collector can be ported to them as
needed; certainly it can't be ported *before* that :) and does anyone
still use the latest XEmacs on a Masscomp, or a Gould, or a Tahoe? Hell,
some of those targets were removed from GCC last year because they'd not
been ported from GCC 1 in ten years, and *nobody* had ever complained...
So I'll bite the bullet and do it, and if it's alreay been done better
or I've done it in an insane manner you can all laugh at me and
--
`LARTing lusers is supposed to be satisfying. This is just tedious. The
silly shite I'm doing now is like trying to toothpick to death a Black
Knight made of jelly.' --- RDD