[Vm-dev] becomeForward: behavior

Florin Mateoc florin.mateoc at gmail.com
Tue Jan 25 20:07:25 UTC 2022


I mean for primitive 72 it should say "Note that the identityHash of the
objects in otherArray are changed, so if any of them was indexed in a
hashed structure, those indexes are now incorrect, so the structures should
be rehashed"

On Tue, Jan 25, 2022 at 2:56 PM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

> I think what the comment should say is "Note that the identityHash of the
> receiver also changes to match its new identity, so if the receiver was
> indexed in any hashed structures, those indexes are now incorrect, so the
> structures should be rehashed"
>
> The comment for primitive 72 should say "Note that the identityHash of the
> argument is changed to match the identityHash that previously belonged to
> the receiver, so if the argument was indexed in any hashed structures,
> those indexes are now incorrect, so the structures should be rehashed"
>
>
> On Tue, Jan 25, 2022 at 2:15 PM Florin Mateoc <florin.mateoc at gmail.com>
> wrote:
>
>> Hi Vanessa and Marcel,
>>
>> Thank you for clarifying.
>> Indeed, my notion of a recent image was a "current release" 5.3 image
>> from a year and a half ago, which does not have the change, so I was indeed
>> referring to primitive 72.
>>
>> Sorry for the confusion,
>>
>> Florin
>>
>> On Tue, Jan 25, 2022 at 1:29 PM Vanessa Freudenberg <vanessa at codefrau.net>
>> wrote:
>>
>>>
>>> @Florin,
>>>
>>> I think nobody has mentioned yet that the behavior of
>>> Object>>becomeForward: in Squeak changed "recently".
>>>
>>> What you were describing is the behavior of primitive 72, which indeed
>>> modified the argument's identity hash.
>>>
>>> More recent Squeak releases use primitive 248 instead, which does not
>>> modify the target's hash. We also introduced primitive 249 which takes a
>>> boolean argument to indicate hash copying.
>>>
>>> @Marcel: I think the comments might be more helpful if they explicitly
>>> mentioned which collections might have to be rehashed, and which (if any)
>>> object is being modified.
>>>
>>> Vanessa
>>>
>>> On Tue, Jan 25, 2022 at 03:44 Marcel Taeumel <marcel.taeumel at hpi.de>
>>> wrote:
>>>
>>>>
>>>> Hi Florin --
>>>>
>>>> > it changes the identityHash of the argument, the non (obvious)
>>>> target.
>>>>
>>>> I updated the comment in #becomeForward: ... hope it helps:
>>>>
>>>> "Primitive. All variables in the entire system that used to point to
>>>> the receiver now point to the argument. Fails if either argument is an
>>>> immediate such as a SmallInteger, or if the receiver is read-only.
>>>> NOTE THAT the identityHash of the receiver IS NOT copied to the
>>>> argument so that the argument should still be properly indexed in any
>>>> existing hashed structures after the mutation. See
>>>> #becomeForward:copyHash:."
>>>>
>>>> Best,
>>>> Marcel
>>>>
>>>> Am 24.01.2022 15:11:09 schrieb Florin Mateoc <florin.mateoc at gmail.com>:
>>>> Hi Clément and Marcel,
>>>>
>>>> You are right, other use cases are supported, and there is probably no
>>>> need
>>>> for a separate setIdentityHash: primitive.
>>>>
>>>> I guess I would not have minded if the method currently called
>>>> #becomForward: would have been called #becomeForwardCopyHash: (plus a
>>>> big,
>>>> fat comment). As it is, it is not strictly a one way become method, it
>>>> is a
>>>> combination method instead, and its comment does not reflect that.
>>>>
>>>> Best,
>>>> Florin
>>>>
>>>>
>>>> On Mon, Jan 24, 2022 at 3:00 AM Marcel Taeumel
>>>> wrote:
>>>>
>>>> >
>>>> > Hi Florin, hi Clément --
>>>> >
>>>> > yes, that's what Squeak's #becomeForward:copyHash: is for.
>>>> >
>>>> > See this discussion, where the interference between #becomeForward:,
>>>> copy
>>>> > hash, and ModificationForbidden is explained:
>>>> >
>>>> >
>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208596.html
>>>> >
>>>> > Best,
>>>> > Marcel
>>>> >
>>>> > Am 24.01.2022 08:04:38 schrieb Clément Béra :
>>>> > Hi Florin,
>>>> >
>>>> > I believe there are 2 primitives for 2 different use-cases:
>>>> > - primitiveArrayBecomeOneWayNoCopyHash 248
>>>> > - primitiveArrayBecomeOneWayCopyHash 249
>>>> >
>>>> > The difference between both is which hash is preserved. I think for
>>>> your
>>>> > use-case you should use the other primitive.
>>>> >
>>>> > On Mon, Jan 24, 2022 at 5:04 AM Florin Mateoc
>>>> > wrote:
>>>> >
>>>> > >
>>>> > > Hi,
>>>> > >
>>>> > > I am a bit surprised by the #becomeForward: behavior in Squeak.
>>>> This is
>>>> > a
>>>> > > one way become, where the target of the operation is the receiver,
>>>> which
>>>> > > sheds its identity/existence. Nobody points to it after the
>>>> primitive
>>>> > > execution, so it is discarded. This understanding also conforms to
>>>> the
>>>> > > method comment.
>>>> > > As such, I remember a pattern of usage in VisualAge Smalltalk,
>>>> where one
>>>> > > way become was used as a cheap cleanup/avoidance of memory leaks,
>>>> by
>>>> > doing
>>>> > > oneWayBecome: nil. It's not that I advocate for it, but this works
>>>> in
>>>> > > Squeak too, except in Squeak #becomeForward: does an additional
>>>> thing to
>>>> > > the pointers redirection, it changes the identityHash of the
>>>> argument,
>>>> > the
>>>> > > non (obvious) target. While I understand this may be useful in
>>>> certain
>>>> > > situations, I think it is a dangerous conflation of activities. A
>>>> new
>>>> > > primitive that sets the identity hash could be used (VA has it)
>>>> > explicitly
>>>> > > instead when such behavior is desired.
>>>> > > As it is, if I do "Object new becomeForward: nil", it succeeds and
>>>> it
>>>> > > changes nil's identityHash.
>>>> > >
>>>> > > Sorry if this has been debated before,
>>>> > >
>>>> > > Cheers,
>>>> > > Florin
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > Clément Béra
>>>> > https://clementbera.github.io/
>>>> > https://clementbera.wordpress.com/
>>>> > Hi Florin,
>>>> >
>>>> > I believe there are 2 primitives for 2 different use-cases:
>>>> > - primitiveArrayBecomeOneWayNoCopyHash 248
>>>> > - primitiveArrayBecomeOneWayCopyHash 249
>>>> >
>>>> > The difference between both is which hash is preserved. I think for
>>>> your
>>>> > use-case you should use the other primitive.
>>>> >
>>>> > On Mon, Jan 24, 2022 at 5:04 AM Florin Mateoc
>>>> > wrote:
>>>> >
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> I am a bit surprised by the #becomeForward: behavior in Squeak. This
>>>> is a
>>>> >> one way become, where the target of the operation is the receiver,
>>>> which
>>>> >> sheds its identity/existence. Nobody points to it after the
>>>> primitive
>>>> >> execution, so it is discarded. This understanding also conforms to
>>>> the
>>>> >> method comment.
>>>> >> As such, I remember a pattern of usage in VisualAge Smalltalk, where
>>>> one
>>>> >> way become was used as a cheap cleanup/avoidance of memory leaks, by
>>>> doing
>>>> >> oneWayBecome: nil. It's not that I advocate for it, but this works
>>>> in
>>>> >> Squeak too, except in Squeak #becomeForward: does an additional
>>>> thing to
>>>> >> the pointers redirection, it changes the identityHash of the
>>>> argument, the
>>>> >> non (obvious) target. While I understand this may be useful in
>>>> certain
>>>> >> situations, I think it is a dangerous conflation of activities. A
>>>> new
>>>> >> primitive that sets the identity hash could be used (VA has it)
>>>> explicitly
>>>> >> instead
>>>> >>
>>>> >> when such behavior is desired.
>>>> >> As it is, if I do "Object new becomeForward: nil", it succeeds and
>>>> it
>>>> >> changes nil's identityHash.
>>>> >>
>>>> >> Sorry if this has been debated before,
>>>> >>
>>>> >> Cheers,
>>>> >> Florin
>>>> >>
>>>> >>
>>>> >
>>>> > --
>>>> > Clément Béra
>>>> > https://clementbera.github.io/
>>>> > https://clementbera.wordpress.com/
>>>> >
>>>> >
>>>> Hi
>>>> Clément and Marcel,
>>>>
>>>> You are right, other use cases are supported, and there is probably no
>>>> need for a separate setIdentityHash: primitive.
>>>>
>>>> I guess I would not have minded if the method currently called
>>>> #becomForward: would have been called #becomeForwardCopyHash: (plus a big,
>>>> fat comment). As it is, it is not strictly a one way become method, it is a
>>>> combination method instead, and its comment does not reflect that.
>>>>
>>>> Best,
>>>> Florin
>>>>
>>>>
>>>> On Mon, Jan 24, 2022 at 3:00 AM Marcel Taeumel <marcel.taeumel at hpi.de>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi Florin, hi Clément --
>>>>>
>>>>> yes, that's what Squeak's #becomeForward:copyHash: is for.
>>>>>
>>>>> See this discussion, where the interference between #becomeForward:,
>>>>> copy hash, and ModificationForbidden is explained:
>>>>>
>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208596.html
>>>>>
>>>>> Best,
>>>>> Marcel
>>>>>
>>>>>
>>>>> Am 24.01.2022 08:04:38 schrieb Clément Béra <bera.clement at gmail.com>:
>>>>> Hi Florin,
>>>>>
>>>>>
>>>>>
>>>>> I believe there are 2 primitives for 2 different use-cases:
>>>>>
>>>>> - primitiveArrayBecomeOneWayNoCopyHash 248
>>>>>
>>>>> - primitiveArrayBecomeOneWayCopyHash 249
>>>>>
>>>>>
>>>>>
>>>>> The difference between both is which hash is preserved. I think for
>>>>> your
>>>>>
>>>>> use-case you should use the other primitive.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 24, 2022 at 5:04 AM Florin Mateoc
>>>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>> > Hi,
>>>>>
>>>>> >
>>>>>
>>>>> > I am a bit surprised by the #becomeForward: behavior in Squeak. This
>>>>> is a
>>>>>
>>>>> > one way become, where the target of the operation is the receiver,
>>>>> which
>>>>>
>>>>> > sheds its identity/existence. Nobody points to it after the
>>>>> primitive
>>>>>
>>>>> > execution, so it is discarded. This understanding also conforms to
>>>>> the
>>>>>
>>>>> > method comment.
>>>>>
>>>>> > As such, I remember a pattern of usage in VisualAge Smalltalk, where
>>>>> one
>>>>>
>>>>> > way become was used as a cheap cleanup/avoidance of memory leaks, by
>>>>> doing
>>>>>
>>>>> > oneWayBecome: nil. It's not that I advocate for it, but this works
>>>>> in
>>>>>
>>>>> > Squeak too, except in Squeak #becomeForward: does an additional
>>>>> thing to
>>>>>
>>>>> > the pointers redirection, it changes the identityHash of the
>>>>> argument, the
>>>>>
>>>>> > non (obvious) target. While I understand this may be useful in
>>>>> certain
>>>>>
>>>>> > situations, I think it is a dangerous conflation of activities. A
>>>>> new
>>>>>
>>>>> > primitive that sets the identity hash could be used (VA has it)
>>>>> explicitly
>>>>>
>>>>> > instead when such behavior is desired.
>>>>>
>>>>> > As it is, if I do "Object new becomeForward: nil", it succeeds and
>>>>> it
>>>>>
>>>>> > changes nil's identityHash.
>>>>>
>>>>> >
>>>>>
>>>>> > Sorry if this has been debated before,
>>>>>
>>>>> >
>>>>>
>>>>> > Cheers,
>>>>>
>>>>> > Florin
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Clément Béra
>>>>>
>>>>> https://clementbera.github.io/
>>>>>
>>>>> https://clementbera.wordpress.com/
>>>>>
>>>>> Hi Florin,
>>>>>
>>>>> I believe there are 2 primitives for 2 different use-cases:
>>>>> - primitiveArrayBecomeOneWayNoCopyHash 248
>>>>> - primitiveArrayBecomeOneWayCopyHash 249
>>>>>
>>>>> The difference between both is which hash is preserved. I think for
>>>>> your use-case you should use the other primitive.
>>>>>
>>>>> On Mon, Jan 24, 2022 at 5:04 AM Florin Mateoc <florin.mateoc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am a bit surprised by the #becomeForward: behavior in Squeak. This
>>>>>> is a one way become, where the target of the operation is the receiver,
>>>>>> which sheds its identity/existence. Nobody points to it after the primitive
>>>>>> execution, so it is discarded. This understanding also conforms to the
>>>>>> method comment.
>>>>>> As such, I remember a pattern of usage in VisualAge Smalltalk, where
>>>>>> one way become was used as a cheap cleanup/avoidance of memory leaks, by
>>>>>> doing oneWayBecome: nil. It's not that I advocate for it, but this works in
>>>>>> Squeak too, except in Squeak #becomeForward: does an additional thing to
>>>>>> the pointers redirection, it changes the identityHash of the argument, the
>>>>>> non (obvious) target. While I understand this may be useful in certain
>>>>>> situations, I think it is a dangerous conflation of activities. A new
>>>>>> primitive that sets the identity hash could be used (VA has it) explicitly
>>>>>>
>>>>>> instead
>>>>>>
>>>>>>
>>>>>>
>>>>>> when such behavior is desired.
>>>>>> As it is, if I do "Object new becomeForward: nil", it succeeds and it
>>>>>> changes nil's identityHash.
>>>>>>
>>>>>> Sorry if this has been debated before,
>>>>>>
>>>>>> Cheers,
>>>>>> Florin
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Clément Béra
>>>>> https://clementbera.github.io/
>>>>> https://clementbera.wordpress.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220125/cb71f399/attachment-0001.html>


More information about the Vm-dev mailing list