Re: [Gc] Changing ‘GC_should_collect’ to account for malloc’d memory

Bruce Hoult bruce at hoult.org
Sun Feb 27 05:28:42 PST 2011


On Mon, Feb 28, 2011 at 1:29 AM, Ludovic Courtès <ludo at gnu.org> wrote:
>> The person writing the application code could make a reasonable guess,
>> or use dtrace or other tools to measure it once and then hard code it.
>> Or proxy malloc() themselves.
>
> So in the iconv example, you would give libgc an /estimate/ of amount of
> heap associated with ‘iconv_t’, right?
>
> The problem is that the estimate could vary greatly from system to
> system.  Wouldn’t it be risky to base GC decisions on such
> approximations?

Maybe, but not worse than assuming it is zero :-)

Where I said "the person writing the application code" above, I meant
whoever is writing the GC code. In the case of a language
implementation such as Guile this would be the Guile implementors, not
the end users writing scheme code.


> My proposal implicitly makes the assumptions that all heap allocations
> (malloc and GC_MALLOC) are related.
>
> I think it’s reasonable in the case of Guile where most malloc’d C
> objects provided by C libs are associated with a GC_MALLOC’d Scheme
> object that has the same lifetime.

So it would be reasonable for Guile to proxy or replace malloc.  Or
run a test program during building of the compiler on each system
type.

I don't think it is reasonable for the GC itself do do these things
but only to provide a way to tell the GC how much space to take
account of.

Do you have any objections to the idea to make this part of the
finalization API?



More information about the Gc mailing list