[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