[MLton-devel] Minimizing space usage in ML (fwd)
Wed, 23 Oct 2002 13:29:12 -0400 (EDT)
> What is the point to change something to immutable?
So that the GC optimization could coalesce it with an equal object.
> I would think that it is
> a choice of either mutating it even though it is immutable (bad if the GC
> optimization goes in)
Are you talking about a linearity optimization? For example:
val t1 = (1,2)
val t2 = (#1 t1, 3)
val t3 = (4, #2 t2)
(* no future uses of t1 or t2 *)
(Forget that this could all be evaluated at compile time.) Then, although
t1 is an immutable object, we could potentially mutate its first and then
second component to produce t3. In the absence of the GC optimization,
then this would be o.k.; in the presence (as Henry points out) this would
be very bad -- if t1 were allocated as an immutable object.
> or leaving it mutable until you know it will never be
> mutated again.
This is what Stephen and I have in mind. An array is mutable until it is
"Vector_fromArray"-ed, in which case it becomes immutable. Likewise, we
could allocate t1 as a pair of mutable slots (hence, the tuple as a whole
is mutable), until the second update, at which point we could reclassify
the tuple as immutable.
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
MLton-devel mailing list