[Vm-dev] becomeForward: behavior

Tue Jan 25 19:15:05 UTC 2022

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/3e46bdb4/attachment-0001.html>