This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Simplify handling of ggc_push/pop_context


On Wed, May 23, 2001 at 12:59:45PM -0700, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:
> 
>     Zack> case.  In the pushed-contexts case, objects at different
>     Zack> context depth can no longer share contexts, so that will
>     Zack> take more space, but not much.
> 
> Please measure this by compiling, say, one of the
> template-instantation files in the V3 library.  We also use contexts
> for template instantiation, which can nest heavily, so the lack of
> sharing makes me a bit nervous.

There is a large penalty in the number of pages used, and it doesn't
self-correct the way I thought it would.

old code:
file		true peak 	peak after GC	pgs at EOF	alloc at EOF
string-inst	 7880k		 7844k		 6488k		 4171k
misc-inst	   15M		   15M		   13M		   10M
valarray-inst	 7020k		 6988k		 6806k		 5444k
locale-inst	   17M		   17M		   16M		   13M

new code:
string-inst	10148k		10100k		 9536k		 4171k
misc-inst	   27M		   27M		   25M		   10M
valarray-inst	 7276k		 7216k		 6976k		 5444k
locale-inst	   27M		   27M		   26M		   13M

The first three columns are _pages_ allocated, the last is _objects_
allocated.  You can see that the new scheme can require almost twice
as many pages to hold the same objects.

I thought it might help to change the 'threshold' code (the thing that
throttles collections if we haven't allocated that much memory yet) so
it counted in total pages, not objects, but that made it worse:

new code, threshold measured in pages:

string-inst	   11M		   11M		 9484k
misc-inst	   35M		   35M		   26M
valarray-inst	 7668k		 7608k		 7368k
locale-inst	   32M		   32M		   26M

And forcing collections every time we get to ggc_collect and the
allocation depth is above the collection depth, causes cc1plus to
crash.  This would be a bug somewhere else, possibly with my code.

So this approach needs more work before we can consider it seriously,
alas.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]