2006/5/3, Daniel Berlin <[EMAIL PROTECTED]>:
The number of *host* systems we support that don't have mmap is
approaching 0, if it is not there already :)
Uhm, at least DJGPP as a GCC host system is alive and does not support
mmap. But according to the following discussion, that's non-issue.
Mark and compact is of course, another option here :).
Yes. Of course, it has the same issue with missed pointers as copying
collectors do.
We could attempt stack walking to alleviate this, but there have been
concerns about doing that, too :).
This is certainly possible. There is an issue that unitialized areas
in the stack may pose as valid pointers and thus render some of the
garbage uncollectable. An experiment with Boehm's GC could provide
some insight into how much it would affect a GGC, as it does stack
walking.
Some people have talked about mark and compact before too,
Couldn't find any discussion about mark and compact in GCC context,
any pointers?
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.
Makes sense. So, regardless of final collector investigation results,
it's a good idea to have an additional side-outcome of the project:
make GCC have only one GGC.
OK, so based on the next round of comments here is the next iteration
of the rough plan:
1) Investigate possibility of Boehm GC usage for compiler proper.
1.1) Issues to be considered:
1.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.1.2) Performance. Boehm's GC should be consistently faster than
existing collectors by a healthy margin, about 10%.
1.2) The investigation would be done with a quick-and-dirty hacking of
build system and throwing together a ggc-boehm.c wrapper. Both of
these are supposed to be thrown away later.
2) If Boehm GC turns out to be viable option, integrate it.
2.1) Build system integration. Documentation tells that Boehm GC GNU
style build system is incomplete. Practically that means that for any
GCC hosts, which don't support Java already, GNU-style build system
bits have to be written for Boehm GC. Shouldn't be too many such
systems or too complex.
2.2) Developing proper ggc-boehm.c. Implement external interface
functions of ggc.h. Exploit things like GC_malloc_atomic for
performance tuning. Throw away helper functions in ggc.h and most of
the ggc-* stuff.
3) If Boehm GC is not a viable option, work on existing collectors.
3.1) Develop a copying collector
3.1.1) Find a solution for root pointer in local variables. By this
time should be clear from Boehm GC investigation results if stack
walking is viable for GCC. It would be preferred because no
modifications all over GCC would be required.
3.2.2) Have a fallback for a non-mmap, non-mprotect system in the same
collector.
3.2) Develop a generational collector. A first design idea is to have
three generations. Objects would be promoted from the 1st to 2nd
generation after surviving a single collection, from 2nd to 3rd after
surviving additional few (more than one) collections. Some of the
objects with a known lifetime (medium or very long) could be put
straight into 2nd or 3rd zone.
4) Testing. I have access to x86, with some additional effort I could
also test on amd-x64 and sparc hosts. I assume that I will have to
arrange for tests on a number of additional host architectures, that's
where I will probably need some help.
What's still unresolved with this plan:
1) How does PCH interact with GC and what will I have to do about it.
2) Copying collector as a milestone concerns me a bit. Would GCC
accept a collector that doubles its memory requirements, in the (let's
hope, unlikely) case that I don't finish generational GC?
Obstack resurrection investigation sounds interesting, but for now I
exclude it from the plan. It may reappear there later, depending on
how things turn out.
Thanks again for your comments and looking forward for more feedback.
--
Laurynas
