On Mon, Aug 13, 2012 at 5:47 PM, Phil Clayton <[email protected]> wrote: > This can be worked around easily, for example by creating a variant of > PolyML.export that adds a final PolyML.fullGC to the exported function (for > both normal and exception paths). However, there is the question of > whether, on termination, a full GC is needed or does a call to each > finalizer suffice. If it is the latter, the work-around with an explicit GC > does more work than required.
I would think that you would want a full GC. I wouldn't expect a finalizer to run unless the value it is finalizing has been garbage collected, and it is possible that some code might depend upon that invariant. If there is code that should run at the end of the program, whether or not a value has been garbage collected, then OS.Process.atExit seems to be the better choice. > By comparison, for stand-alone executables created with MLton, any remaining > finalizers (added with MLton.Finalizable.addFinalizer) are called prior to > termination - possibly due to a final GC, I don't know. Actually, it is due to multiple final GCs. The implementation is at: http://mlton.svn.sourceforge.net/viewvc/mlton/mlton/trunk/basis-library/mlton/finalizable.sml The loop is to handle the situation where a full GC reveals that some finalizers should be run and, after running the finalizers and discarding those closures, another full GC reveals that yet more finalizers should be run. -Matthew _______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
