[gclist] Timeliness of finalization

[Giuliano Carlini]

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

GC>4) Timeliness of finalization. I haven't heard a reason for why finalizers must run
within
GC>a small window of time after the last reference to them is dropped. Perhaps I missed it.
The
GC>arguments I have heard describe the scarcity problem: you must finalize quickly to
GC>release a scarce resource. Are there any other latency issues?

CF> You have just won the billion dollar lottery! A dollar a year for a billion years!

Hi Charles,

If your granting me a billion year lifespan, I'll be quite happy with that and not worry too
much about the sedentary rate at which you satisfy your promise ;->

CF> You have a list of a million items and it takes a complete collection cycle
CF> to finalize the first item, then another to finalize the second. This is the
CF> actual result of some collector finalization algorithms. If the finalizers
CF> must be run for a correct program result the program is busted.
CF> 
CF> Finalizers must be "sure" to protect encapsulation. If they aren't "prompt"
CF> they aren't "sure".

This isn't what I was asking about. I wanted examples of when timeliness is important.
I've thought of one, but I'd still like to hear about others.

The one I've thought of are expensive resources. To continue the socket example stated by
someone else, imagine a high speed socket connection running over a satellite. Now
satellite time is amazingly expensive from what I've heard. Imagine it took a minute from
the time the program last used the connection to the time the collector found the
unreachable connection and ran the finalizer which shuts down the connection. I
wouldn't want to pay for that  minute of satellite time that I didn't use.

The counter argument is that resource leaks will usually be more expensive than slow
finalization. If we use only explicit deallocation to shutdown the connection we will
almost certainly leak some connections. And one leaked connection that stays up for an
hour will be as expensive as 60 connections that took a while to finalize.

So, the ideal solution is probably to use both. Explicitly deallocate resources. Let the
collector's finalizer calls handle the cases you forgot about.

g

--=_ORCL_33980189_0_11919703281955230
Content-Type:message/rfc822

Date: 28 Mar 97 13:26:47
From:"Charles Fiterman <cef@geodesic.com>" <majordom@iecc.com>
To:gclist@iecc.com
Subject:[gclist] Timeliness of finalization
Reply-to:gclist@iecc.com
Return-Path:<majordom@iecc.com>
Sender:majordom@iecc.com (MajorDomo)
X-Sender:mail38454@alterdial.uu.net
X-Mailer:Windows Eudora Pro Version 2.2 (32)
Precedence: bulk
Errors-to:owner-gclist@iecc.com
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="us-ascii"

>4) Timeliness of finalization. I haven't heard a reason for why finalizers must run within
>a small window of time after the last reference to them is dropped. Perhaps I missed it. The
>arguments I have heard describe the scarcity problem: you must finalize quickly to
>release a scarce resource. Are there any other latency issues?

You have just won the billion dollar lottery! A dollar a year for a billion years!

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.

Finalizers must be "sure" to protect encapsulation. If they aren't "prompt"
they aren't "sure".

How small the window of time is a quality of implementation issue but a
bad enough quality of implementation is worthless. Just like that lottery
ticket, the faster they pay off the better. Or would you accept a penny a century?
			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A computer language without garbage collection
  is like a city without garbage collection.

--=_ORCL_33980189_0_11919703281955230--