[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