serialization
Stephen Weeks
sweeks@wasabi.epr.com
Tue, 17 Aug 1999 14:58:27 -0700 (PDT)
> I'm still not convinced this is a bug per se although I do agree it comes
> awfully close. When globalization is applied to
>
> val f = let val r = ref 13
> in fn () => (r := !r + 1; p("global", r))
> end
>
> I presume the ref cell bound to r is turned into a top-level binding; when f is
> serialized, only a reference (not a copy) to this binding is recorded. When f
> is subsequently restored, what is the environment in which it is deserialized?
> From the example, it appears this environment contains the original reference
> binding of r to 13.
Correct.
> In the case of g, since there's no such reference to a
> top-level cell, the increments happen as we expect.
Ah, but there is, depending on whether or not the globalizer is smart
enough to globalize the ref creation. In the example I mailed, I
carefully constructed the "nontail" function to confuse the optimizer.
If I had changed nontail to a simple loop, or even fn x => x, then the
globalizer would have figured out the g's ref cell could be
globalized.
> I gather things would work if globalization is turned off for mutable objects
> which are involved in a serialization operation. How hard would it be to have a
> pass that marks reference allocation points that may be serialized, having the
> globalizer not globalize these objects?
In Cps land it shouldn't be too hard to write such a pass.
Unfortunately, there is a bit of globalization that goes on in the
closure converter, just to keep the environments from getting insanely
huge. In particular, it wants to close over the unit refs in
exceptions so that everybody and their brother doesn't have to be
closed over Subscript, Size, etc.
Hmmm, this makes me wonder. What's going to happen if deserialized
objects start raising exceptions? I guess this is more like Henry's
example where you want the Subscript exception to be the same across
all address spaces, and hence you want to *not* close over the ref
cell. Arggggggggh!
Maybe the right solution is to disallow serialization of mutable
objects (or functions, since they may be closed over mutable
objects).