[MLton] space safety for structures
Henry Cejtin
henry@sourcelight.com
Fri, 2 Jul 2004 16:10:27 -0500
I would still argue strongly that in the more complicated case
structure S =
struct
val l = <big object>
val x = <small object>
end
structure T =
struct
val _ = <long computation>
end
structure U =
struct
val _ = <use of S.x but not S.l>
end
then S.l is dead way before the <long computation> is evaluated.
Part of my argument is based on the fact that structures are NOT run-time
objects, they are just namespace control.
The argument about separate compilation is some what of a red herring in my
opinion because even with that, garbage collection requires global knowledge.
The problem is simply being caused not so much by separate compilation as by
the REPL. Once you have a REPL, all globals, or any thing in scope of the
REPL, must be viewed as part of the root set.
Once you have a notion of a closed world (no more `use'), safe for space in
the MLton sense is clearly the way to go (I claim). As you say, it requires
a global liveness, but that is just because that liveness is doing part of
the GC at compile time (which is good). Switching to inserting black-hole
code would be pushing some of the GC back to run time (not good).