[Vm-dev] [squeak-dev] Object new becomeForward: #normal

Chris Muller asqueaker at gmail.com
Thu Jul 20 22:45:57 UTC 2017


>> >> This is debatable ... I would rather have the VM raise an error when
>> >> trying to become a field of an immutable object. Immutable should mean
>> >> immutable, no?
>>
>> So for bulkBecome:, will the error mean it becomed some of them (the
>> ones that that could), but not all?   It's getting complex!
>
>
> None of them.  The semantics of primitives should be they either succeed and answer their result, or they fail without side-effects.  Alas the ImageSegment loading primitive is an exception, but I believe it's the only one.  So in the become primitives, validation is done before any becomes, including computing an estimate of any memory needed, and the entire bulk become will fail if any single object fails validation and/or if there is not enough memory to complete the operation (two-way become may involve creating copies of objects).

Okay, that sounds like a good principle.

>> > However, it seems to me that becomerForward: doing a copyHash is itself a
>> > bug.  What's the rationale for copying the receiver's hash to the target
>> > object?
>>
>> For when you become a Proxy object to a Symbol selector to perform,
>> which are keys in MethodDictionary's.  It's absolutely essential.
>
>
> This doesn't make sense to me.  Are you saying one has a proxy for a Symbol that is not present, this gets entered as a key into MethodDictionaries, and later is becalmed into the Symbol it represents?  If not, can you take me through the use-case?
>
> It seems to me that what one wants is the ability to determine an Object's identityHash.  I've long thought that Symbols should set their identityHash on creation so that Symbols identityHashes are constant across all systems.  This would men for example, that binary code loaders would not need to rehash method dictionaries because they would already be correctly hashed.  In these cases one definitely doesn't want to overwrite the target's identityHash; instead, taking your example, one would want to create the proxy with the identityHash of its target.

Woops, I misread this sentence:

>> > However, it seems to me that becomerForward: doing a copyHash is itself a

I thought you meant NOT copying the hash was a bug.  In fact, we agree
that copying (changing) the identityHash of the target object is not
very safe or useful.  Sorry for the confusion.

So, yeah, the scenario is the Magma app materialized an object which
references a Proxy.  Then that proxy was agitated (sent a message -->
DNU), whereupon the Symbol string is read from the DB and the Proxy
becomeFoward'ed to it.  But it was a Symbol that already existed in
MethodDictionary's, so its identityHash shouldn't change just because
of that.

Best.

PS -- Here is the first message of the first thread which was the
birth of the #becomeForward:copyHash: addition to the VM.   :)

     http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-May/039735.html


More information about the Vm-dev mailing list