[MLton-devel] GC finalization

Henry Cejtin henry@sourcelight.com
Thu, 13 Jun 2002 00:05:51 -0500


Here  is  some  mail  exchanged between Allen Leung and myself of the SML-Gtk
interface.  My take is that the former is really going to leak memory because
they  don't have any finalization support.  In fact, in the last message from
Allen he says that for his current project he had to switch  from  SML/NJ  to
OCaml precisely because of the lack of finalization support.

I  claim  that  all  of  this  is  another vote for putting some finalization
support into MLton.  The only tricky semantics in this come if you  want  the
finalization  code  to  get  a  reference  to the object which is about to be
destroyed.  In that case, you have to have revived the object,  and  then  it
might  not  actually be dead any more, even though you performed finalization
on it.  I could live with that, but it does require  care  to  avoid  leaking
memory.

It  is all a bit trickier for MLton given its aggressive data re-arrangement,
but for things like interfacing to C code, all one would need would be a kind
of weak ref holding an address (Word32.word) which, on creation you provide a
function to call (on the Word32.word) when the weak ref becomes garbage.

>From leunga@dorsai.org  Wed Jun 12 22:46:37 2002
>From: Allen Leung <leunga@dorsai.org>
>Subject: Re: SML-Gtk question
>To: henry@sourcelight.com (Henry Cejtin)
>Date: Wed, 12 Jun 2002 23:55:08 -0400 (EDT)
>
>>I  have  been  looking  at your SML-Gtk bindings thinking how to do something
>>similar for MLton, but I am completely missing something: how do the  objects
>>ever  get free'd?  I didn't see any support for finalization in SML/NJ, and I
>>didn't see any code trying to do it in the SML-Gtk stuff.  I re-read  Blume's
>>No  Longer Foreign, but there is no mention there either of any way to do it.
>>What is the secret?
>>
>>Thanks
>
>   It's no secret: no object is ever freed automatically.
>
>   Gtk internally keeps track of reference counts for its own widgets.
>Normally the client has to manage this manually via calls like
>gtk_widget_unref and gtk_widget_destroy.  This is also true in SML.
>
>   I don't see any easy way to get around this problem, even with
>finalization support in the gc -- having a finalizer simply call
>gtk_widget_unref is incorrect.
>
>From henry@sourcelight.com  Wed Jun 12 22:53:53 2002
>Date: Wed, 12 Jun 2002 22:53:53 -0500
>From: Henry Cejtin <henry@sourcelight.com>
>To: henry@sourcelight.com, leunga@dorsai.org
>Subject: re SML-Gtk question
>
>Thanks  for  such a fast response, but I remain confused.  With finalization,
>why wouldn't just calling unref in  the  finalizer  be  correct?   I.e.,  one
>reference from the heap has just been lost.  The other references (from other
>widgets, etc.) would have to be counted by the code  which  does  an  add  or
>pack, but I would have guessed that it is already.
>
>I  was  using  SML-Gtk  as an argument for why we need to add finalization to
>MLton's GC, so if I am missing something, please tell  me.   I  really  don't
>want  to  have  MLton  leaking memory (or referring to things already free'd,
>which would clearly be even worse).
>
>Say hello to Andrew Wright for me.  All of this was started by some mail from
>him  about  things  he wanted in MLton so that he could try to get it used at
>Aleri, which would certainly be great.
>
>From leunga@dorsai.org  Wed Jun 12 23:29:10 2002
>From: Allen Leung <leunga@dorsai.org>
>Subject: Re: re SML-Gtk question
>To: henry@sourcelight.com (Henry Cejtin)
>Date: Thu, 13 Jun 2002 00:38:04 -0400 (EDT)
>
>>Thanks  for  such a fast response, but I remain confused.  With finalization,
>>why wouldn't just calling unref in  the  finalizer  be  correct?   I.e.,  one
>>reference from the heap has just been lost.  The other references (from other
>>widgets, etc.) would have to be counted by the code  which  does  an  add  or
>>pack, but I would have guessed that it is already.
>
>   I suspect that is not correct.  I think a reference count kept by gtk
>is the sum of references from other widgets, but it does not include
>references from the stack or other user data. For example, normally the
>user never calls gtk_widget_ref/unref for pointers to GtkWidget on the stack.
>So if the finalizer calls unref it will deallocate an object too early,
>because its references in the sml heap are not normally counted.
>I guess one way of thinking of it is that gtk is using some sort of
>deferred reference counting scheme (with a not-too-well-defined policy.)
>
>   I suppose we can fix this by implicitly calling gtk_widget_ref when
>we create a new pointer to a GtkWidget on the sml heap, but I'm not
>sure this won't run into other difficulties.  For example, when we use the
>FFI interface to store a widget pointer into another widget inside SML
>(possible with Matthias ml-nlffigen) we have to manually call gtk_widget_ref
>to increase the reference count; I don't see how this can be made automatic.
>
>>I  was  using  SML-Gtk  as an argument for why we need to add finalization to
>>MLton's GC, so if I am missing something, please tell  me.   I  really  don't
>>want  to  have  MLton  leaking memory (or referring to things already free'd,
>>which would clearly be even worse).
>
>   I think finalization will be a crucial thing to have in "real life"
>applications that have to interface to C.  In fact, one of the reasons
>I have to abandon sml/nj for ocaml in my current project is because of
>the lack of finalization support the former.
>
>   In the gtk situation, the real problem is that gtk has its own idea
>how to do memory management which conflicts with sml's gc.    In any case, the
>lack of automatic memory management in sml-gtk is not such a big problem;
>Gtk programs in C (and thus sml) very rarely has to do manual reference
>counting.
>
>>Say hello to Andrew Wright for me.  All of this was started by some mail from
>
>   Sure will.
>
>>him  about  things  he wanted in MLton so that he could try to get it used at
>>Aleri, which would certainly be great.
>
>From henry@sourcelight.com  Wed Jun 12 23:51:50 2002
>Date: Wed, 12 Jun 2002 23:51:49 -0500
>From: Henry Cejtin <henry@sourcelight.com>
>To: henry@sourcelight.com, leunga@dorsai.org
>Subject: Re: re SML-Gtk question
>
>I would have thought that the Gtk stuff would automatically keep track of its
>own references, (widget to widget), but would leave the C code to keep  track
>of  its  references  to objects.  Something like this must be going on since,
>for instance, Python, with its own reference-counting scheme, interacts  well
>with Gtk and doesn't seem to leak.
>
>If  they  are  sane,  always in question for people using reference counting,
>then something like *_new would return an object with a reference count of 1.
>Then there is the question of if adding the result to another widget requires
>you to increase the count, or if that is done for you.  It's all a bit silly,
>but  it  still  seems to me that once you unravel what their conventions are,
>finalization is enough to make it live with a properly GC'd  world.   Without
>it  it must be the case that a program that just loops creating new top-level
>windows (or buttons for a window) which it then destroys is going to leak.
>
>With regards to having to move from SML/NJ to OCaml, that would  really  hurt
>me.  The implementation of OCaml is very nice, but the syntax (like having to
>declare  records)  and  circular  lists  being  allowed  would  really  hurt.
>Definitely  another  example  of  how  MLton  needs  finalization.  I'll send
>Stephen Weeks another vote in that direction.
>
>Thanks again


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel