[Vm-dev] becomeForward: behavior

[Clément Béra]

There is also a setIdentityHash: primitive that we use to set the hash of
specific classes known to the VM. Not sure if it should be used besides
building the kernel though.

On Mon, Jan 24, 2022 at 3:10 PM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

>
> 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/
>>
>>

-- 
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/20220124/74f7d050/attachment-0001.html>