[MLton-devel] supporting weak pointers

[Stephen Weeks]

> > I think that mGTK should work
> > just fine with support for only unreachability detection, without any
> > need for a post-gc-hook.  They can build their own finalization out of
> > weak pointers and do the memory management, e.g., once per callback.
> 
> I've never taken a really hard look at finalization, but I thought it was
> a harder problem than the above.  Java is always making a big deal about
> trying to get finalization right; problems with order of evaluation,
> bringing GCed values back "from the dead", etc.

Sorry.  I misspoke.  I didn't mean to imply that one could build a
general purpose finalization mechanism, e.g. 

	val finalize: 'a * ('a -> unit) -> unit

I meant to say that with weak pointers, the mGTK guys could solve the
problem for which they were requesting finalization support.  Since I
don't want to deal with all the messy problems of full-fledged
finalization, weak pointers seems like a nice compromise.  Hopefully
they will agree.

> With the above, it seems as though you would need keep two copies of every
> C pointer.  Keep them in (Cword weak * Cword) pairs in some structure,
> where the weak one is "released" to the rest of the ML program.

This is roughly what I had in mind, except that instead of using
(Cword weak * Cword) pairs, I would propose for them to use (GTKObj *
Cword), where GTKObj has the Cword somewhere within it.  That
sidesteps the messiness with Cword weak due to Cword not being
pointer.

> Periodically, check if the weak pointer has been freed; if so, perform
> some C side deallocation via the saved Cword.

Yes.  And the periodically that I had in mind was per callback.

> This is consistent with SML/NJ's weak pointers.  MoscowML's weak pointers
> are more like weak refs, and support
>   val set: 'a t * 'a -> unit
> to make a weak pointer point to a new object.  It seems that set would be
> easy enough to incorporate with the implementation, although it will need
> to mark pages the same way that reference or array updates do.

I would leave out set for now on the grounds that it's one more thing
to worry about.  But you're right that adding it wouldn't be too hard.

> You mention that the mark-compact GC will need to recognize weak
> pointers and treat them specially.  That would seem to require
> updating the MemChunk type.

I was hoping to avoid that.  But I think you're right, it looks
unavoidable given the way that we currently do mark-compact.  If we
ever switch to using a table to do the pointer updates instead of
pointer threading, then we could treat the mark-compact just as we do
the copying gc, with a walk over all the weaks just before sliding all
the objects.


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel