serialization

[Suresh Jagannathan]

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.  In the case of g, since there's no such reference to a 
top-level cell, the increments happen as we expect.

Indeed, this does have the feel of the kind of problems we had with Kali in
which top-level mutable cells were not copied in messages essentially requiring
programs to not depend on their machine-local values.  It's an interesting
example, and in some ways more insidious than what happens in Kali because the
programmer doesn't actually see the globalization transformation, and must now
be required to deeply understand the behavior of the optimization in order to
figure out the anomolous behavior.

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?

	   -- sj