[Gc] weak maps and libgc
hans.boehm at hp.com
Mon Nov 7 17:23:32 PST 2011
Sorry about the belated reply. Again.
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai at mail.ru]
> Sent: Wednesday, October 26, 2011 2:36 AM
> To: Boehm, Hans; Andy Wingo
> Cc: gc
> Subject: Re: [Gc] weak maps and libgc
> Hi Hans,
> What's your opinion of these 3 ideas?
> PS. Anyway, it won't go into 7.2 branch.
> 26 10 2011, 13:05 Andy Wingo <wingo at pobox.com>:
> > Thanks for the thoughts, Ivan!
> > On Wed 26 Oct 2011 10:18, Ivan Maidanski <ivmai at mail.ru> writes:
> > > 26 10 2011, 00:06 Andy Wingo <wingo at pobox.com>:
> > >> (1) a variant of GC_register_disappearing_link that also
> > >> incremented an `unsigned long' somewhere in memory
> > >
> > > You mean statistic counter, right?
> > > Good idea.
> > Yes, but ideally one that can be associated with a particular memory
> > location. So, collecting a weak reference in collection A would
> > increment a counter associated with A, but not affect a counter
> > associated with collection B.
I'm not sure I understand all the trade-offs here. But isn't this doable with (possibly chained) finalizers already? I don't have a very strong feeling either way, but this doesn't feel like a particularly clean interface addition to me.
> > > Is my understanding correct - you want to optimize the following:
> > >
> > > // assume GC_general_register_disappearing_link(&link, obj1); ...
> > > GC_unregister_disappearing_link(&link);
> > > GC_general_register_disappearing_link(&link, obj2);
> > >
> > > Right? If yes, I don't mind again.
I'm OK with that one, too. It seems a bit esoteric, but it has a clean definition, and there seems to be a clear performance gain. It would be nice if it didn't get pulled in for embedded clients that don't use it and care about code size.
> > OK, great. (Embarrassingly, late yesterday I realized that part of my
> > overhead was caused by terrible flaws in my hash functions, causing
> > extra collisions and thus reshuffling. It's not often that you get to
> > replace a hash function and speed up your program by 25%!)
> > >> (3) It would be nice if there were a callback after GC. It would let
> > >> me accurately measure the time in GC, for example. This isn't
> > >> relevant to the current discussion though.
> > >
> > > What's about existing GC_set_start_callback?
> > That callback is tricky, because you can't do much in it. But it is
> > good for starting a timer. Then you need a GC_set_stop_callback to
> > stop the timer and record the time spent in GC.
> > Another thing a GC_set_stop_callback would be useful for would be
> > statistical profiling of the causes of GC -- just sample the call
> > stack in the stop callback. Such a sampler is likely to allocate
> > memory though and so it's not appropriate for a start callback.
I'm OK with this IF you can reasonably define what it means. What does it mean with incremental/generational GC? Is it invoked only at the end of full collections? Can you get two concurrent invocations for different GCs because the first one didn't finish before the second one started? If not, how do you prevent it?
> > Regards,
> > Andy
> > --
> > http://wingolog.org/
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
More information about the Gc