Reference counting

John M McIntosh johnmci at ibm.net
Thu Oct 28 05:06:36 UTC 1999


> "John M McIntosh" <johnmci at ibm.net> wrote...
> [and I think John actually knows most of what's here.  I just felt there was
more to be said]
>>As pointed out one of the strange things that one can do in some flavors of
>>Smalltalk is take back an about to be GCed object. As part of finalization
>>you can make a strong reference and effectively forbid the GCing of the
>>object. Mind you it makes my head hurt why you would want to do this!
>
> Well, in a perfect world, you should never have to.  But there are reasons.
>  Usually they have to do with tracking some other system without the
> benefit of actual references.  The most common example is to close or
> delete a file when ST no longer refers to it.  If the file operations were
> embedded in a transaction, then control could not emerge to the point of
> releasing the file without proper wrap-up.  Or if the file mechanism were
> all in ST (*), the GC could sweep it away and no one would be the wiser.
> That's how it's supposed to be.  But the truth is that there usually IS
> another reference to the bits on the disk, but ST can't see it.  So
> finalization in such cases provides a mechanism for ST to retrieve the
> external reference, make it visible, and complete the transaction in an
>appropriate manner.
>

Agreed, the other case were I've seen this type of pattern used is dealing
with external OS database session. However both these cases deal with having
Smalltalk sync or do housekeeping between it's viewpoint and the hosting OS.
I'm more interested in hearing about examples where one would take back
about to be GCed object as part of solving a business problem.

{Regarding your cache flushing at close/GC time. Apple did this quite a
number of years ago and it had one problem. If your cache was very large,
and if you had lots of dirty blocks, then on the close flushing all those
blocks took a long long time since each block was a separate I/O}

>>Regarding Latency, an example. Given this simplified code
>>
>>thing isAnOrange ifTrue: [Transcript show: thing color]
>>
>>Many times I've seen a walkback, nil does not understand color, but what
>>happened, how could thing which just responded to the isAnOrange message
>>become nil? Well a GC occur and thing just well disappeared.
>
> Let me know if this ever happens in Squeak.  I don't believe this
> particular example is in any gray area -- it's flat wrong.  The variable
> 'thing' should hold onto its referent throughout this expression.  I can't
>imagine using a system with this problem.
>
> I have seen such a thing happen in Smalltalk, but it was due to a
> reentrancy bug where there was shared access to the variable 'thing',
> another process got tirggered between the two sends, set 'thing' to nil, and
>then gave control back.  But that's not what you were talking about.
>
> I can also imagine a perverse situation where isAnOrange does a become
>operation, but that's not what you were talking about either.
>
>  - Dan
>

Dan you are correct my example is poor and has been too simplified, that's
what I get when I talk about weak references late at night, the dog wanted
out, I was in a hurry etc. But I did twitch when I hit the enter key last
night, and today I'm paying for it since I had to go back and dig out my
notes to better explain what I was REALLY talking about.

>>thing isAnOrange ifTrue: [Transcript show: thing color]

As Dan points out the example is flawed without additional knowledge.
'thing' of course usually is an instance variable or a temp and firmly
attached to the execution context so it's not going to GC heaven.

But in my notes I've two examples

The first example deals with Corba based Smalltalks, after building a few
you forget how specialized they are. The Corba ORB in your image keeps weak
references to your objects so you don't have to tell the ORB when to GC
them, and of course to enable objects to get GCed when they need to be GCed.
If the Orb kept a strong reference then someday you'd have problems because
you'd forget to make that little call to sync your view of garbage with it's
view.

Example 1

| thing |

thing := Foo new asCorbaObjectReference
thing isAnOrange ifTrue: [Transcript show: thing color]

This may or may not fail when we execute the ifTrue statement since 'thing'
of course is not an instance of Foo, it's a Corba Object Reference which
weakly refers to the instance of Foo you've created. The 'thing' or I should
say Corba proxy  uses information contained within it to hunt down the
actual object and execute the method against it and return the results, it
all happens transparent via doesNotUnderstand, just step over it and it
behaves like any other message send. Problem with this code fragment is that
we no longer have a strong reference to the instance of Foo we just created.
So based on when finalization occurs different results can happen.

Visual clues, when clouded by other code, certainly don't show you that it's
a Corba call so unless you knew that 'thing' was an Corba Object Reference
versus an instance of Foo you would be quite confused when 'thing color'
failed.

Example 2

This problem occurred when a developer got a hold of a weak reference to a
database session and as far as he was concerned it was strong. It work just
fine until the session was closed and the strong reference disappeared.
Again a specialized case where you deal with weak references as if they were
strong.

At least in Visualworks when you get 0 does not understand the message color
then perhaps you were dancing too much on the edge of weak references, or
was that razor blades.

I hope I didn't confuse anyone too much and would be glad to answer any
further questions about finalization etc..

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================





More information about the Squeak-dev mailing list