Hi, Thanks for your comments. I'm replying to both emails at once, as they are related.
2006/5/3, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> - Assuming that Boehm GC turns out to be unusable for the compiler, > finish the zone collector. Again, searching mailing list about what's > unfinished was not very fruitful. What's there works. I don't remember if it is sufficiently portable to e.g. systems without mmap to use as the default; and it needs some performance tuning still, probably, although I did a lot.
I've looked into it and I see that it, in fact, is not portable to systems without mmap. What's more, a patch to make it such at http://gcc.gnu.org/ml/gcc/2004-05/msg00349.html was rejected with a hint that GCC really needs a generational collector. 2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>:
> I wrote a lot of the current zone collector. Before that, Daniel > Berlin did a lot of work on it. I really don't think I have time to > mentor an SoC project (Daniel, do you, maybe?), I do, in fact, have time to mentor such a project, and would be happy to mentor it if you submit it and it is accepted.
Thanks for your support! Based on your feedback and on mailing list archive mining, I've made several conclusions. None of them is supported by hard data, so if they're obviously wrong, correct me. 1) Object lifetimes: in general unpredictable, but there are significant number of short-lived and very-long-lived objects. 2) Heap fragmentation is an issue (that's why copying collector is desirable?) 3) If copying (copying-generational included) collector is to be implemented, GCC sources would require some cleaning up of missed roots (pointers in local variables that are used after ggc_collect() call) Based on this, I have following refinement of my initial plan: 1) Investigate possibility of Boehm GC usage for compiler proper. Issues to be considered: 1.1) Portability. Boehm's GC portability should at least match that one of ggc-zone, if gcc-page is not going away. Obviously, if Boehm GC would replace all ggc-* collectors, then it must be as portable as GCC itself, with possibility of graceful degradation of GC performance, if that's acceptable. 1.2) Performance. Boehm's GC should be consistently faster than existing collectors by a healthy margin. (How much is enough? 10%? 20%?) 2) If Boehm GC turns out to be viable option, integrate it. 3) If not, work on existing collectors. Drop the idea of finishing ggc-zone as it is (because its portability fixes were already rejected, see above) and work on making it copying generational collector. The development of copying generational collector could be splitted to the development of simple copying collector first, then using that as a basis for the generational one. There are some risks here (again, correct me if I'm wrong) associated with copying GC: that a lot of patching all over GCC would be required it to work (those pointers in local variables). If that turns out to be a very big problem, then I remember seeing references to the generational collectors that are not copying, so considering them would be logical. Thanks again and looking forward for more comments, -- Laurynas
