[gclist] Finalization and object orientation.

[Giuliano Carlini]

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

RE:
	I am considering the following scheme. Objects have an int
	getFinalizerOrder() and a void setFinalizerOrder(int n) method.
	If you need a pre-finalized version of object X you use
	  setFinalizerOrder(X->getFinalizerOrder() + 1);
I'd recommend against setting an absolute order by using integers. As your example shows,
you don't really care about the absolute order, but rather the relative order. In the
past, I've used objects to represent dependencies. Dependencies are just arcs in a
directed graph:
	class Dependency : GraphArc...
So, to denote that "this" depends on "X" and therefore must be finalized after it:
	Graph	finalizerDependencies;
	finalizerDependenies.add( new Dependency( this, X ) );
Coming up with a dependency order is now just a topological sort:
	Iterator i;
	i = finalizerDependencies.topoSort();


g

--=_ORCL_33946328_0_11919703281532350
Content-Type:message/rfc822

Date: 28 Mar 97 11:41:44
From:"Charles Fiterman <cef@geodesic.com>" <majordom@iecc.com>
To:gclist@iecc.com
Subject:Re: [gclist] Finalization and object orientation.
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"

At 10:59 AM 3/28/97 -0800, you wrote:
>On Mar 28, 12:04pm, Charles Fiterman wrote:
>> While you can't guarantee running finalizers at the earliest possable
>> moment you can guarantee running them. At end of job you can sort
>> remaning finalizers in finalizer order number sequence and run them.
>> Approaching the earliest moment is a quality of implementation issue.
>>
>The problem with static finalizaton ordering is that it's hard to sort out the
>system issues.
>
>If I'm implementing a type A and type A objects refer to type B objects during
>finalization, type A needs to know type Bs finalization order sequence number.
> The programmer needs to remember finalization order dependencies in order to
>get this right.  And getting it wrong in the presence of native methods is
>likely to result in memory smashes.

I am considering the following scheme. Objects have an int getFinalizerOrder()
and a void setFinalizerOrder(int n) method.

If you need a pre-finalized version of object X you use
  setFinalizerOrder(X->getFinalizerOrder() + 1);
which would be abbreviated
  finalizeBefore(X);
If you need a post-finalized version of object X you use
  setFinalizerOrder(X->getFinalizerOrder() - 1);
which would be abbreviated
  finalizeAfter(X);

Finalizer order numbers default to 0. Yesterday I thought the correct default
was MAX_INT. Today I realized that finalizers might add value not mearly
subtract it. What ever problems this kind of scheme has it must be the mutators
problem not the collectors. If their are cycles and hard to sort out system
issues they only become harder by handing them to the collector.
			-  
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_33946328_0_11919703281532350--