Re: Forthcoming revisions to the garbage collector; crazy huge hack

On 22 May 2001, Michael Livshin stated: That has one advantage; it keeps fragmentation down. Maybe this is why that was done. It could well cause cacheline problems as well as data locality problems... ... but it can't fail to have better locality at GC time than the XEmacs GC system; and like it or not right now a busy XEmacs is GC-bound. What does Hans say about this criticism? Knowing Hans he's probably benchmarked it to death :) Much much smaller though, because they're cut up :) also, the massive slowdowns caused by GC pulling all of Emacs out of swap even if it's almost never used for anything but GC traversal are improved. Agreed; the allocator part of the Boehm GC doesn't look ideal as an allocator... I might see if I can rejig it in terms of an underlying malloc(), so we can use the nice general purpose malloc()s to do the allocation, and Boehm to do the GC. (But that's a blue-sky far future project, I think.) I expect there to be some space wastage from that, yes. But all that wastes is swap, because the unreferenced object is, well, unreferenced; and I'm willing to burn a bit of swap in order to get that better VM behaviour. (It's *horrible* running XEmacs on 16--24Mb machines; the swapping at each GC can take 45 seconds or more!) I'm not sure if 5.3 can do that; there's DATASTART, but messing with that is a bit hairy (OK, it's very nasty 'cos it's one of the nonportable defined-differently-for-everyone options.) I plan to turn off ALL_INTERIOR_POINTERS, if it doesn't kill XEmacs. That should drastically reduce the number of incorrectly retained blocks; and in any case 5.x has got much better at spotting these blocks and zapping them. 4.x was worse, 3.x was horrible :) 5.x isn't bad. It teaches me a lot about XEmacs ('cos I've got to read most of the code to audit it for GC-safety). That's one of my primary goals. :) Something like Bartlett's Mostly Copying collector? That too looks nice; if the overhead of the Boehm collector is too high, I might well try the Bartlett one instead (note that I'm trying to make the changes to the XEmacs code itself independent of any one GC implementation; this is one reason why). I avoided it for fear that its VM performance would be worse, and because Richard Jones says in his wonderful GC book : A study of the comparative performance of the Boehm-Demers-Weiser : Conservative Collector and the Mostly Copying Collector would be : interesting, although as usual performance would be heavily dependent : on implementation detail. One may speculate that Mostly Copying might : perform better in an environment with a high allocation rate of : short-lived objects [...] and Emacs has lots and lots of objects with very long lifetimes indeed; the exact opposite of this case. (See my original reasoning, above. This just backs it up a little bit.) ML in particular has very different allocation patterns to Emacs; huge numbers of tiny, short-lived allocations are common, with very little long-term persistent state. Allocation performance is *really* important in that environment, while what matters here, I think, is GC latency and overhead. -- `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