Is become: still Platform dependently one or two way?

[Joachim Tuchel]

Inspired by some discussion on the Pharo mailing list - we discussed become: nil vs become: String new in the context of garbage collection and freeing image space - I took a look at Object>>#become:

The comment in this method says:

     The exact implementation of #become: is platform
     dependent. Some implementations may swap the
     references of the receiver and otherObject. This is
     termed 'two way' become. For 'two way' become, answer
     otherObject. Some implementations will only change
     the references that originally refer to the receiver
     leaving otherObject to be garbage collected. This is
     termed 'one way' become.

 

Is this still true in the new VM? Which platforms use what? What consequences might this have for my daily work if I try to clean up things by become: nil ?

We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

Joachim

[Seth Berman]

Hi Joachim,

@see this discussion also: https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ

We maintain the same algorithms for this in the new vm as with the old...which is one-way become on all our supported platforms today.

I don't personally see that changing, though perhaps there are versions of old visualage running around that did it differently.

"What consequences might this have for my daily work if I try to clean up things by become: nil"

That's a big question...depends on how your objects will react when you replace what they had in their slot with nil.

But if you mean in terms of two-way become, then its not an issue.

- Seth

[Joachim Tuchel]

Hi Seth,

Thank you very much for this clarification.

So VAST does one-way become on all currently supported platforms. Maybe in that case it would be good to either change the comment in Object>>become: to not make it sound as if it may be one of these two, or at least add a line stating that all platforms supported by [version] are one-way.

This sure isn't a pressing issue, so if it doesn't make it to Version 2021, that's likely not a problem.

Joachim

[Seth Berman]

Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

- Seth

[Joachim Tuchel]

Oh, maybe I should have mentioned I was checking on 9.1, so if you worked on this method's comment in 9.2x, this is probably obsolete...

[Seth Berman]

Hi Joachim,

No, its unsurprisingly the same. 

I would love to say the team has the time to validate the correctness of old 1996 comments in a codebase our size...but that just wouldn't be true:)

However, we are happy to clarify for folks that request it.

- Seth

[Hans-Martin Mosner]

Am Donnerstag, 2. April 2020 12:56:50 UTC+2 schrieb Joachim Tuchel:

We've implemented an object database a few years ago and it is still in use by one of our clients. It heavily uses become: for replacing proxies with their real ovbjects once they've been read from the DB (it's currently only used on Windows). Would this cause any side effects on platforms that implement a two-way-become?

If you create the real objects just before you do the #become: and don't reference them later there should be no difference.

Variables which previously held the proxies will point to the real objects now in any implementation.

In a one-way become implementation, the variable in which the newly created object was held will still hold it, while in a two-way become implementation it will point to the proxy now. If you forget this variable, there is no difference anymore.

One think that still might be different is the treatment of object hash - in a two-way become system, the objects exchange their hashes, too. This is not possible in a one-way become.

As Seth already pointed out, VA is going to stay with the one-way become, so you should not expect issues. However, if you want to write portable code that works with a two-way become, you should definitely not use "become: nil" as it will break your image.

Cheers,

Hans-Martin

[Douglas Swartz]

Historical content:  I worked with VA Smalltalk as early as version three. At that time, VA used one way become on Windows and Unix.  I suppose it's possible the MVS mainframe version used two way.  

I suspect the comment dates back to Envy/Smalltalk and OTI where they were delivering Smalltalk versions for various platforms. 

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4ac0257-0c46-4973-bed3-7aa19ba04b7f%40googlegroups.com.

[Richard Sargent]

On Thursday, April 2, 2020 at 4:56:34 AM UTC-7, Seth Berman wrote:

Hi Joachim,

Sure, I'm sure we can clarify the comment a bit.

Given my other recent post, consider factoring out the current implementation into a #oneWayBecome: method and using it explicitly. That would make it easier for people to use the two-way become when they want to and to explicitly distinguish when they need a one-way become, and yet have the eternal default implementation.

Well named code is always better than comments for explain what is being done. Let the comments explain the why.