Smalltalk › Instantiations

Is become: still Platform dependently one or two way?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

jtuchel

Is become: still Platform dependently one or two way?

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/6683db22-d959-43a6-ac6b-1093d1e4806d%40googlegroups.com.

Seth Berman

Re: Is become: still Platform dependently one or two way?

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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/f77cef87-324c-4d59-85e9-fc1d0a64f76f%40googlegroups.com.

jtuchel

Re: Is become: still Platform dependently one or two way?

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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:

Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;">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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/52e8c352-85a5-4730-9bd2-358b7b38a91c%40googlegroups.com.

Seth Berman

Re: Is become: still Platform dependently one or two way?

Hi Joachim,

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

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:

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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;">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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/165a29e5-5ef4-4482-8810-8fef0294b899%40googlegroups.com.

jtuchel

Re: Is become: still Platform dependently one or two way?

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

Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:

Hi Joachim,

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

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;">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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5ac37f6f-6ff6-49da-ad12-7dd186f42bb9%40googlegroups.com.

Seth Berman

Re: Is become: still Platform dependently one or two way?

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

On Thursday, April 2, 2020 at 8:10:59 AM UTC-4, Joachim Tuchel wrote:

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

Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:
Hi Joachim,

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

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;">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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4ac0257-0c46-4973-bed3-7aa19ba04b7f%40googlegroups.com.

Hans-Martin Mosner-3

Re: Is become: still Platform dependently one or two way?

In reply to this post by jtuchel

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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1d6c51e9-9173-4335-ab8b-e1a7616fd8d7%40googlegroups.com.

Douglas Swartz

Re: Is become: still Platform dependently one or two way?

In reply to this post by Seth Berman

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.

On Thu, Apr 2, 2020, 7:14 AM 'Seth Berman' via VA Smalltalk <[hidden email]> wrote:

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

On Thursday, April 2, 2020 at 8:10:59 AM UTC-4, Joachim Tuchel wrote:
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...

Am Donnerstag, 2. April 2020 13:56:34 UTC+2 schrieb Seth Berman:
Hi Joachim,

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

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb 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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/d4ac0257-0c46-4973-bed3-7aa19ba04b7f%40googlegroups.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAF3kYMXG0iymZBHNxiPkHXB-jVVzyQYfnk10B77tAQZGBGABbA%40mail.gmail.com.

Richard Sargent

Re: Is become: still Platform dependently one or two way?

Administrator

In reply to this post by Seth Berman

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.

- Seth

On Thursday, April 2, 2020 at 7:45:32 AM UTC-4, Joachim Tuchel wrote:
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

Am Donnerstag, 2. April 2020 13:31:53 UTC+2 schrieb Seth Berman:
Hi Joachim,

@see this discussion also: <a href="https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;" onclick="this.href='https://groups.google.com/d/msg/va-smalltalk/SjfzgI8INDI/uPohZpJ_gcUJ';return true;">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

On Thursday, April 2, 2020 at 6:56:50 AM UTC-4, Joachim Tuchel wrote:
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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2a28f858-735b-4bcf-94ea-33752900832e%40googlegroups.com.