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
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@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
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.htm... [http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208596.htm...]
Best, Marcel Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@gmail.com [mailto:florin.mateoc@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.github.io/] https://clementbera.wordpress.com/ [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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
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@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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
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@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.htm...
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@hpi.de [mailto:marcel.taeumel@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.htm... [http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-April/208596.htm...]
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra <bera.clement@gmail.com [mailto:bera.clement@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.github.io/]
https://clementbera.wordpress.com/ [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@gmail.com [mailto:florin.mateoc@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.github.io/] https://clementbera.wordpress.com/ [https://clementbera.wordpress.com/]
@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@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@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.htm...
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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
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@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@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@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.htm...
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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
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@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@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@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@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.htm...
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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
On Jan 25, 2022, at 11:57 AM, Florin Mateoc florin.mateoc@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"
I think that wording is misleading. What happens is that all references to the receiver(s) are replaced by references to the target(s) (this is a bulk become). So the receiver, is fact, obliterated. So hashed collections that used to contain the receiver(s) now contain the target(s) and must 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@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@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@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@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.htm...
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@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.htm...
Best, Marcel > > Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/ > >
I agree, your wording is better. I think both #becomeForward: and the bulk become methods should include the comment (slightly differently phrased), as people looking at the #becomeForward: method won't necessarily read the comment of the underlying bulk become method Both should mention that the indexes where the target(s) are now stored are incorrect.
I also think that both primitive 72 and primitive 248 should have a comment to that effect. In both cases we start with two different objects and we come out with only one. Regardless of the choice of which identityHash to use, one of the original objects loses (if it was previously included in a hashed collection), so there is potentially extra work to be done
On Tue, Jan 25, 2022 at 3:07 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Jan 25, 2022, at 11:57 AM, Florin Mateoc florin.mateoc@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"
I think that wording is misleading. What happens is that all references to the receiver(s) are replaced by references to the target(s) (this is a bulk become). So the receiver, is fact, obliterated. So hashed collections that used to contain the receiver(s) now contain the target(s) and must 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@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@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@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@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.htm...
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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
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@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@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@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@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@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.htm...
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@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.htm...
Best, Marcel
Am 24.01.2022 08:04:38 schrieb Clément Béra bera.clement@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@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/
vm-dev@lists.squeakfoundation.org