This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: thanks for the memory work
- From: law at redhat dot com
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 25 Nov 2003 22:28:12 -0700
- Subject: Re: thanks for the memory work
- Reply-to: law at redhat dot com
In message <ACCDC166-1FC8-11D8-90B7-000A95DA505C@dberlin.org>, Daniel Berlin wr
ites:
>> Well, you avoid the overhead of having an array for each one, and if
>> you
>> have 328,000 of them, that has to be something at least. the GC doesnt
>> have to deal with them.PLus, I was planning to do some thing about the
>> 0
>> and 1 DEF case, much like I did with immediate_uses, they oughtn't take
>> much to deal with.
>
>The cost of ggc allocated varrays actually a lot worse than you think.
Not really.
>Try to count the number of times the array is grown (IE we don't get
>the size exactly right for the entire lifetime).
>Now, note the use of ggc_realloc in varray.c
>
>Then look at what ggc_realloc does in ggc-common.c.
>
>Now count the number of times the array is grown again, and cry.
And this is a surprise in what way?
Without a completely new set of data structures this is exactly what
I would expect when I don't know how big of an array I'm going to
need.
It would be nice if there was a way to immediately recover the storage
in the original varray and make it available for reuse. In fact, in
general it would be nice if we could tell the GC system that a
particular object is no longer in use and that it should be made
available for recycling immediately.
Jeffkk