Re: Forthcoming revisions to the garbage collector; crazy huge hack
Nix <nix(a)esperi.demon.co.uk> writes:
I'm doing what should have been done a *long* time ago; ditching
the
garbage collector and replacing it with a nicer one. I think everyone
can agree that XEmacs's garbage collector currently sucks really rather
hard; I don't think there are any ways to worsen its VM behaviour or
intrusiveness if we tried.
[...]
The one I've picked is the Boehm collector; it's not terribly portable,
but that can be fixed fairly easily --- and it lets us dump bloody GCPRO
and all the uglinesses it has spawned over the years (blocking string
compaction, Lispification in redisplay and many other things).
The Boehm collector only has one downside that I can see; unportability
(it's not portable to some of the more obscure platforms that XEmacs
runs on).
the other downside is its quite pessimal data locality characteristics
(it groups objects according to their size -- great for lists, sucks
for everything else). whether it matters for XEmacs -- dunno, perhaps
not. I've seen one system where it made quite a huge difference, when
compared with a custom copying collector.
- (on some platforms) full incrementality/generationality; we can say
a
near-total goodbye to GC delays on those platforms
um, not really. it does help, but the delays are still there,
especially if your heap is fragmented (and it will become so, as
people tend to run one Emacs instance for weeks).
- the death of GCPRO, and therefore probably also of
gc_currently_forbidden
and similar variables. This is my other major motivation; portable
though it is, I *hate* GCPRO with a passion. (Besides, walking the
stack is not that unportable; the unportabilities in the Boehm
collector are in other areas, like incremental collection.)
the problem with walking the stack is not the unportability, it's the
conservatism.
you might want to tinker with the code to switch off the data segment
scanning, BTW (I don't think it's a run-time option).
Plus, I think it's a fun hack.
er. if you consider living in gdb fun, yes. ;)
(btw, I think we should under no circumstances implement a copying
collector; they get less and less impressive the bigger the heap and the
longer-lived its objects, and XEmacs has a large heap and a very large
set of long-lived objects, mainly thanks to the obarray.)
last I heard, generational copying collectors were doing quite well.
I believe all the major commercial (and most of the free) Common Lisp
and *ML systems use such collectors.
good luck,
--mike
--
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich on comp.lang.c++