[gclist] Finalization and object orientation.

[Eliot & Linda]

Hans Boehm wrote:
> 
> Greg Colvin wrote:
> 
> > Right, except that Java's finalization call is not required to do anything
> > at all.
> 
> It would be hard to require it to do something precise without seriously
> inhibiting optimization.  Certainly it could not require that unreachable
> objects with finalize methods be finalized.  (Gosling, Joy, and Steele
> define a reachable object to be one that "can be accessed in any potential
> continuing computation from any live thread".  This is clearly undecidable
> in general.)

It is undecidable only in systems allowing the computation (forgery) of
object pointers.  In languages like Java, Smalltalk, Self etc where one
can only construct a valid pointer by instantiation, and where there is
no computation on object pointers then it is impossible to forge or
otherwise disguise pointers.  In this context it is a decidable problem
(a scan followed by a trace will divide objects into reachable and
unreachable ones).  However, latency and ordering of the running of
finalizers is a harder problem.  However, it is easy for the system to
provide base-line guarantees such as "every as-yet unfinalized
unreachable
object with a finalizer will be queued for finalization before the end
of
any global scan-mark garbage collection".  Being able to provide
guarantees
like this, and hence being able to rely on facilities such as
finalization,
is an important reason to require total garbage collection over
approximations such as conservative GC.

> Language definitions usually leave many properties related to resource
> usage undefined.  Those are usually beyond the scope of the definition.
> We have to be willing to assume that implementations
> make reasonable choices.  I believe a standard-conforming C implementation
> can reserve a gigabyte for every integer (to accomodate those really big
> integers without dynamic storage allocation :-)).  Yet this doesn't seem
> to be a real problem.
> 
> RunFinalization may be more of a problem in the short run.  But it seems
> to me that likely that implementing it as a noop wil eventually be viewed
> about as badly as gigabyte integers, at least for a conventional workstation
> implementation.
> 
> Hans
> 
> Hans-Juergen Boehm
> boehm@mti.sgi.com

_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace-Digitalk, eliot@parcplace.com