2006/5/4, Mark Mitchell <[EMAIL PROTECTED]>:
In the long run, I don't think we really want to be using garbage collection at all.
[...]
All of the above should not in way be read as an argument against using the zone collector -- it's actually an argument in favor of improving the zone collector! It's going to take a while to do the bits above, and having better GC is going to help us until then. The great thing about the zone collector is that it's a step in the memory pool direction; it's zones can be the things I called pools. Whether we use GC on those pools, or turn the zones into obstacks, or whatever, is a separate step.
Thanks for your long-term insights. I've done some quick hacking around the code to clear a thing or two for myself. Below are things I've found out. - Cygwin's mmap() is still buggy. There was a lot of work on it previously, the last message I could find on the subject was http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00521.html . It suggested, that Cygwin's mmap() maybe could be un-blacklisted now. Well, it cannot. Zone collector unearths the problem that munmap(address, some_amount) actually unmaps 64KB when some_amount is e.g. 20KB. I've tested both MMAP_ANON and /dev/zero. If anybody is interested, I can provide the testcases. If nobody is, then maybe someday I'll find time to make testcases directly against Cygwin libc. For GCC it means that any mmap'y collector, if it's to become a single GCC collector, will need additional work here. It is possible to implement a workaround (free only 64KB worth of adjacent free pages) at cost of some memory expense, or use valloc(), or the malloc() code from ggc-page. Of course, only the first option is viable for copying collector. I wonder if cygwin's mprotect() has a set of similar issues. - In other news, I've linked Boehm's GC with GGC, provided implementations for ggc_alloc_stat(), ggc_collect(), and stubbed out everything else. The result works only with disabled collection (i.e. Boehm's GC allocation routines and nothing else is used). Otherwise it collects identifier symbol table almost immediatelly after its creation. A little bit of debugging suggests that there is an issue of Boehm's GC being not aware of all roots. This can be solved either moving data structures living partly in malloc() memory, partly in GC memory to one of them or by registering additional roots with GC. - PCH support. I didn't spend enough time to investigate it, so please correct me if required. It seems that it would require either hacking inside of Boehm's GC, either factoring PCH out of GC with possible duplication of some data structures. It looks like PCH is an argument for keeping a custom collector inside of GCC. Regarding the overall plan, I'm thinking how much my previous plan changes in the face of long-term objectives. Probably not much, as both copying and generational collectors would be improvements of the zone collector, so things could be segregated into zones as GCC sees fit. On the other hand, it probably means, that going with Boehm's GC in less likely. Any comments? Now I'm off to write proposal for Google. -- Laurynas
