BlockContext serialization

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Thu Mar 6 02:21:00 UTC 2003


=?iso-8859-1?Q?St=E9phane?= Rollandin wrote:
> 
> what I'm really aiming for is the serialization of a BookMorph embedding 
> dozens of morphs of different kinds. another example where the same problem 
> appears is a morph using a SortedCollection : can't be serialized because 
> of the sort block !
> 
> so I guess I could subclass all problematic classes, including 
> SortedCollection (?), but: if it is a bug, could'nt it be fixed ? I don't 
> know enough to do this by myself I'm afraid.

I just poked around with this, and it looks like the mechanics of
writing and reading the BlockContexts (and associated MethodContexts
and CompiledMethods) is perfectly sound.  I just naively stubbed out
ContextPart>>storeDataOn: and ContextPart class>>basicNew: and
inserted super sends (in the debugger as I encountered the errors they
raise), and traced the process in detail as I saved a block to file
and back.  As far as I can tell, there's nothing suspect about this
process at all.  What I did was:

block1 := [:x | x+1].  <doIt>

rs := ReferenceStream fileNamed: 'test.obj'.
rs nextPut: block1.
rs close.  <doIt>

(These must be separate doIts because otherwise the block's home
MethodContext pulls in the entire stack, and the World with it; and
the World can't be written out while active.)

rs := ReferenceStream fileNamed: 'test.obj'.
block2 := rs next.
rs close.  <doIt>

Inspecting/exploring block1 and block2, one sees that they have the
same structure.  I was able to send  block2 value: 3  and receive
the expected result of 4.  But the image became mysteriously unstable,
to the point that the VM would freeze solid on snapshot.  (This was
repeatable.  MacOS 8.1, VM 3.2.7b6 Classic, Squeak 3.4.)

It was also possible to save a Morph with a block, like so:

Morph new setProperty: #block toValue: block1; saveOnFile  <doIt>

Reading it back in from the file browser was successful, and the block
appeared structurally sound, and essentially identical to the
original.  But in this case, I got a hard freeze when trying to
evaluate the block.

The only noticeable difference between the original and reloaded
blocks in these examples is that bytes 5 through 8 of the
CompiledMethod are different, which if I understand correctly is
expected since this is the reference to the binding for 'block1' in
the original doIt: New object, new bytes.

Whatever's happening here is deeper or subtler than I can understand.

-Jesse



More information about the Squeak-dev mailing list