This is the mail archive of the
mailing list for the libstdc++ project.
Re: compile time regressions (was: merging for 3.4)
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Dan Nicolaescu <dann at ics dot uci dot edu>,"libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc at gcc dot gnu dot org
- Date: Tue, 10 Dec 2002 09:02:51 -0500
- Subject: Re: compile time regressions (was: merging for 3.4)
On Tuesday, December 10, 2002, at 01:37 AM, Neil Booth wrote:
The partial solution to this is generational copying collection.
Dan Nicolaescu wrote:-
It looks like there was a significant increase in the garbage
collection time. It's strange that GC is so expensive for C++
I think GC is turning out to be a mistake, even though it saves
us from nasty memory issues. It means we have no idea what code
is gradually getting worse; it just shows up as "GC". And it
gives poor locality.
(The full solution is to use garbage collected pools/arena so that we
are allocating things we access together, together).
Our poor locality is also generally from the fragmentation of memory
that is occurring.
So is our large footprint.
We could at least start with a non-generational copying collector (to
avoid needing a barrier) and see if it helps.
It's not too hard to turn gengtype into something that emits copying
routines, reusing the mark bit as our bit to determine forwarded
I can actually say it's not too hard because I did it one day when i
Took a few hours, and i never completely finished converting (mainly
didn't feel like transforming the ggc_test_and_set_mark calls and
blocks at the time), but it's doable.
If you zero out the old space, you'll quickly discover where we have
pointers to gc'd info from non-gc'd things.