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

[Ludovic Courtès]

Hi,

Bruce Hoult <bruce at hoult.org> writes:

> On Sun, Feb 27, 2011 at 11:49 PM, Ludovic Courtès <ludo at gnu.org> wrote:
>> Hi,
>>
>> Bruce Hoult <bruce at hoult.org> writes:
>>
>>> I don't think the GC should consider all malloc'd memory, but only
>>> memory which might be freed as a result of a collection.
>>>
>>> It might make sense to have an API that allows objects that register a
>>> finalizer to say how much non-GC memory will be freed when the
>>> finalizer is run.
>>
>> Yes, but in the example above, you can’t tell: there are GC’d objects
>> associated with several KiB of ‘iconv_t’ objects, but you can’t tell
>> exactly how much because it’s glibc that allocates it.
>
> 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?

> I don't think there's any better answer.

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.

Thanks,
Ludo’.