[gclist] Timeliness of finalization

[Giuliano Carlini]

--=_ORCL_33978549_0_11919703281911560
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="US-ASCII"

CF> Finalizers must be "sure" to protect encapsulation.

HB> If you mean that they should run at process exit, then I disagree.  Most
HB> resources should be released by the OS...
HB> you typically do not want to explicitly release resources that
HB> will be released by the OS, since the OS can typically perform the operation
HB> more cheaply.

Hi Hans,

What do you think about running finalizers at exit for non OS objects? It seems that these
must be run at exit. If I create a service, why should I have to support two different ways to
release objects. One which occurs durring normal execution, and one to optimize process
exit? I suspect that usually this would be a misguided microoptimation that saves very
little time. Especially when getting code to run at process exit is typically an
unportable pain in the backside.

Consider C++ streams which buffer output. These clearly must be finalized at exit. Seems
like running finalizers at exit is just the ticket to do this. C++ runtimes currently
manage to do this, but the compiler vendors stoop to some ugly hacks to get it done.

g

--=_ORCL_33978549_0_11919703281911560
Content-Type:message/rfc822

Date: 28 Mar 97 14:19:34
From:"boehm@hoh.mti.sgi.com (Hans Boehm)" <majordom@iecc.com>
To:gclist@iecc.com
Subject:Re: [gclist] Timeliness of finalization
Cc:boehm@hoh.mti.sgi.com
Reply-to:gclist@iecc.com
Return-Path:<majordom@iecc.com>
Sender:majordom@iecc.com (MajorDomo)
In-Reply-To:Charles Fiterman <cef@geodesic.com>        "[gclist] Timeliness of finalization" (Mar 28,  3:26pm)
References:<2.2.32.19970328212647.009111e0@alterdial.uu.net>
X-Mailer:Z-Mail (3.2.3 08feb96 MediaMail)
Precedence: bulk
Errors-to:owner-gclist@iecc.com
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="us-ascii"

On Mar 28,  3:26pm, Charles Fiterman wrote:

> You have a list of a million items and it takes a complete collection cycle
> to finalize the first item, then another to finalize the second. This is the
> actual result of some collector finalization algorithms. If the finalizers
> must be run for a correct program result the program is busted.

This is essentially the same as the cycle problem, with the same solutions.  In
my experience, it's even less frequent in real life.  If the ordering doesn't
matter, it's easy to handle in either scheme.  (Assign them the same order
number, or tell the collector to ignore the list links for finalization
purposes.)  If the order matters and you need to finalize multiple objects per
GC cycle, life gets hard either way, at least if you occasionally insert into
the list.  (You would have to tell the collector that order doesn't matter,
have the finalizer add the elements to a data structure, which you then sort
explicitly.  But this is a pretty contrived problem.)
>
> 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.  You do need to handle resources that are not released.  On
the other hand, you typically do not want to explicitly release resources that
will be released by the OS, since the OS can typically perform the operation
more cheaply.

For those resources that need to be returned on process exit, releasing them is
a very different operation from normal finalization, since global state may
have already been finalized.  Thus I believe it's most reasonable to use a
different mechanism (e.g. registered weak pointers).

Hans

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

--=_ORCL_33978549_0_11919703281911560--