[MLton-devel] supporting weak pointers

[Matthew Fluet]

> The mGTK guys requested support for finalized values so that they can
> do C-side memory management.  To my understanding, finalized values
> consist of two things: a way to detect when a value becomes
> unreachable (e.g. weak pointers), and a "post-gc-hook" that runs the
> finalizers on the unreachable values.  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.

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.
Periodically, check if the weak pointer has been freed; if so, perform
some C side deallocation via the saved Cword.

> The only other issue that I can think of is what to do when the 'a in
> a 'a weak isn't a pointer.  The compiler will know this in the
> SsaToRssa pass.  It seems to me there are two choices.  We can either
> pretend that the 'a is always reachable or always unreachable.  The
> latter is slightly easier, since we can represent the 'a weak as unit
> and implement canGet as fn _ => false.  Threating the 'a as always
> reachable is pretty easy too.  Just implement 'a weak as 'a, canGet as
> fn _ => true, and get as fn x => x, again all within the SsaToRssa
> pass.  If anyone has an argument for going one way or the other, I'd
> be interested to hear it.
>

Neither of the above options really work with the Cword example above.  If
we pretend that the 'a is always unreachable, then the widget will be
deallocated too early.  If we pretend that the 'a is always reachable,
then the widget will never be deallocated.

> So, I propose to add support for weak pointers to MLton.  Here is the
> signature I propose to implement.
>
> signature MLTON_WEAK =
>    sig
>       type 'a t
>
>       val get: 'a t -> 'a option
>       val new: 'a -> 'a t
>    end
>
> So, new creates a weak pointer to an object and get returns SOME of
> the pointer value, unless it has become unreachable in which case get
> returns NONE.

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.

> Well, that's about all I can think of.  It seems like a reasonably
> efficient implementation without too much disruption of the runtime
> or the compiler.  Comments appreciated.

The implementation seems reasonable.  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.





-------------------------------------------------------
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