RE: [Gc] Changing ‘GC_should_collect’ to account for malloc’d memory
hans.boehm at hp.com
Mon Feb 28 18:15:54 PST 2011
I haven't thought this through completely, but ...
The concern I have with registering a number of bytes with a finalizer
is that it's not clear how to reflect that in the GCs
collection heuristic, which basically tries to make sure that we allocate
a given fraction of live data in each GC cycle. Just counting the extra
bytes as part of allocation is probably not right, since the extra bytes
don't live in the GC heap.
Another approach might be to view the iconv_t structures as a second kind of
resource that's managed by the collector. If user code keeps track of how
many such structures are currently in use, it could decide that enough
iconv_t structures have been allocated since the last GC to warrant a
collection, independent of the GC heap situation. That's basically what
you might do if the GC were managing a something like file descriptors:
Force collection when you run out. Here there's no hard limit, but that
actually sidesteps some problems you'd encounter in the file descriptor
I'm not sure that would even require collector changes. With an incremental
collector, GC_gcollect() may be a bit too big a hammer for actually
triggering collections, but that's relatively minor.
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Bruce Hoult
> Sent: Sunday, February 27, 2011 3:01 AM
> To: Ludovic Courtès
> Cc: Andy Wingo; gc at linux.hpl.hp.com
> Subject: Re: [Gc] Changing ‘GC_should_collect’ to account for malloc’d
> 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
> >> 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.
> I don't think there's any better answer.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc