[gclist] Finalization and object orientation.

[Ian Piumarta]

James McCartney <james@clyde.as.utexas.edu> wrote:
> 
> Eliot Miranda <eliot@parcplace.com> wrote:
> >So can we agree that in languages which reify execution state and
> >don't allow pointer forging that reachability is decidable?
> 
> Not as I understand it. x would be reachable by a Smalltalk garbage
> collector, but not truly reachable by the program itself.
> He could have just as well have written:
> 
> Object>>
> ---
> foo
>    | x |
>    x := Something new.
>    self bar.
>    x doSomething.
> -----
> bar
>    true whileTrue: [ ..blah.. ].
> -----
> 
> x is unreachable by the definition given. It doesn't matter that a
> tracing gc would know where it is in an activation frame, the program
> will never access it.

What Eliot's getting at is that the programmer can interrupt the program
while bar is looping, and open a debugger.  From the debugger the user can
trace down the call stack to the context containing x, and so x *can* be
reached.  In Smalltalk there is no way to predict which objects will be
accessed by inspecting the program text, since the user can arbitrarily
interrupt the system and inspect the call stack (which is a linked list of
context objects).

In fact the situation is more complicated in Smalltalk, since the program can
access the pseudo-variable "thisContext" which returns the currently active
context.  Programs can therefore manipulate the active context (and hence all
the rest of the stack) programmatically.  (You can easily implement full
continuations in Smalltalk using this feature, by manually making a copy of
the context chain below the active context.)  So even in your example, #bar
could access x by obtaining a copy of thisContext and following the sender
chain until it reached the context containing x.

boehm@hoh.mti.sgi.com (Hans Boehm) wrote, a few minutes later:
> I think you really have a different notion of reachability in mind.

I think so too.

> I don't know how easy it is to formally define your notion for Smalltalk.
> Do contexts include compiler-introduced temporaries for subexpression
> results?  Is argument evaluation order defined?

Contexts include every value ever generated by the program.  They are used
for arguments, local temporaries, and temporaries generated for intermediate
results.  Everything that you would put on the hardware stack in procedural
language is (potentially) stored in a Smalltalk context during the execution
of the equivalent Smalltalk program -- since the contexts include the local
stack for their associated activation.

Argument evaluation order is defined, but for weak historical reasons.  It's
more efficient on most architectures to evaluate arguments right-to-left,
since that leaves the "receiver" on the top of the stack.  Dan Ingalls (I
think -- it might have been someone else) said someplace that when they
changed the evaluation order from L-R to R-L in an early Xerox PARC
implementation, several people's programs broke and they were promptly asked
to change it back!!

Regards,

Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt,          Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE         Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------