Re: [Gc] Changing ‘GC_should_collect’ to account for malloc’d memory
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
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
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
Do you have any objections to the idea to make this part of the
More information about the Gc