On Wed, 2006-05-03 at 17:18 +0200, Laurynas Biveinis wrote: > 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.
The number of *host* systems we support that don't have mmap is approaching 0, if it is not there already :) > > 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. True, there are certainly sets of trees, rtl, and other objects whose lifetime we know exactly. > > 2) Heap fragmentation is an issue (that's why copying collector is desirable?) Heap fragmentation is a significant issue, and one of the reasons we don't collect very often, so yes. Mark and compact is of course, another option here :). > > 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) This is true. I know a bunch of of such places are from implementing a copying collector :). We could attempt stack walking to alleviate this, but there have been concerns about doing that, too :). Some people have talked about mark and compact before too, but it's hard to find performance numbers for real-world mark and compact collectors. > > 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%?) Probably 10%. The real answer is "enough to outweigh the maintenance cost of boehm-gc vs ggc-page/ggc-zone" > > 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. Again, I'm not sure the portability fixes are a real issue. There is nothing that prevents ggc-zone from being the default on systems with mmap, and ggc-page the default elsewhere. One of the reasons that the portability patches were rejected is that if we want to make ggc-zone copying/generational, any barrier style way of doing so will probably involve mprotect. I've not seen a system that supports mprotect but not mmap. In addition, if it was decided that in order to make ggc-zone the default, it would have to support non-mmap systems, i would accept the portability patches. > > 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. Agreed. > > Thanks again and looking forward for more comments, > > -- > Laurynas >
