[Gc] [boehms-gc] Extend Boehm's GC disappearing link facility withcallbacks-on-disappear

Laurynas Biveinis laurynas.biveinis at gmail.com
Tue Aug 15 09:19:33 PDT 2006


> Isn't this implementable with finalization?

Probably it is, but as far as I can tell not very convienently - in
such implementation client side, e.g. finalizers have to track all the
disappearing links for every object, don't they?

> There is also a long-standing request, posted on the GC list quite
> while ago, by Petter Urkedal I think, to provide a more general callback
> mechanism to allow the client to implement custom weak-pointer like
> things.  He included some largish patches, which unfortunately I've
> never gotten around to massaging a bit and putting into the tree.  I
> think that something along those lines, that essentially allows the user
> to keep a list of "custom" weak pointers, would be a better direction.

This one?

http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/759

I've tried to understand how exactly what I need would look like with
weak pointers provided there and failed. It looks like that this
support is oriented around the objects that disappear. What do I need,
however, is some orientation around the disappearing links (i.e.
callbacks called not for the objects that disappear, but for every
registered disappearing link).

I hope that makes sense. So either I just don't see how this can be
accomplished easily with Petter's patch, or my proposal is a bit
different from that one.


> Callback procedures from inside the collector are generally tricky.
> Deadlock possibilities and the like abound.  I think it's worth devoting
> some effort to documenting exactly what the callbacks can and cannot do.
> They clearly cannot allocate memory.  That means they cannot acquire
> Java locks.  They probably should not generally acquire other locks,
> since threads holding those locks may be blocked on allocation.

As far as my needs are concerned, I can live with very restricted
callbacks. If my proposal lives on, I can document constraints of the
callbacks, but I'm afraid I know too little about collector internals
to do it without your input (I'm sure there are a lot more than you
have just outlined here).

--
Thanks,
Laurynas


More information about the Gc mailing list