[gclist] Timeliness of finalization
Fri, 28 Mar 1997 17:15:56 -0800
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.