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

Ludovic Courtès ludo at gnu.org
Sun Feb 27 05:55:10 PST 2011


Hi,

Bruce Hoult <bruce at hoult.org> writes:

> 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 :-)

It could be worse if it leads ‘GC_should_collect’ to return true more
often than necessary.

> 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.

Yes, of course.

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

Nope.

Actually Guile has historically had such a function,
‘scm_gc_register_collectable_memory’:

  http://www.gnu.org/software/guile/manual/html_node/Memory-Blocks.html#index-scm_005fgc_005fregister_005fcollectable_005fmemory-2450

It doesn’t do anything in 2.0.0, but that could/should probably be
changed when libgc supports it.

Thanks,
Ludo’.



More information about the Gc mailing list