[gclist] Timeliness of finalization

[Hans Boehm]

On Mar 29, 11:08am, stuart  (yeates) wrote:
> Subject: Re: [gclist] Timeliness of finalization
>
> Hans-Juergen Boehm wrote:
> > On Mar 28,  3:26pm, Charles Fiterman wrote:
> > > Finalizers must be "sure" to protect encapsulation.
> >
> > If you mean that they should run at process exit, then I disagree.
> > Most resources should be released by the OS.  Otherwise it's not
> > robust against crashed processes.
>
> This assumes that the garbage collected program isn't the OS itself,
> in which case Charles is correct.
I don't see that.

>
> The talk about JavaOS is evidence that garbage collection is moving
> into low-level systems, and it seems not unlikely that we'll soon
> see 'real' kernels which use garbage collection internally. Such
> kernels must leave hardware (disks etc) in consistent states even
> in the face of crashes.
Are we talking about process crashes, thread crashes,  or OS/machine crashes?
 It's awfully hard to run the finalizers after the power supply failed, or
whatever, so I don't think the latter is possible.  The OS will have to make
sure that the disk is always in a recoverable state, just as it does now.

Thread crashes don't really affect anything.  Process crashes might cause some
synchronous cleanup action sto be invoked, and might remove some roots.  I
don't understand why they would impose constraints on kernel finalization.

>
> Such a system might even be able to handle the case where a subsystem
> throws an uncaught exception (caused by a hardware error or similar),
> and other subsystems NEED to have their finalisers invoked.
Could you clarify?  In a single address space system finalizers are not
associated with subsystems.  They are associated with objects which may be
referenced by multiple subsystems.


Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com