NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/modula3/1150

Internet Message Format | 1993-01-25 | 3.7 KB

Path: sparky!uunet!gatech!udel!darwin.sura.net!spool.mu.edu!hri.com!noc.near.net!nic.umass.edu!nic.umass.edu!hudson
From: [e-mail] (Rick Hudson)
Newsgroups: comp.lang.modula3
Subject: Re: references, objects & m3
Message-ID: <[e-mail]>
Date: 25 Jan 93 22:00:41 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Lines: 54
NNTP-Posting-Host: yough.ucc.umass.edu
In-reply-to: [e-mail]'s message of 25 Jan 93 19:35:20 GMT

>>>>> On 25 Jan 93 19:35:20 GMT, [e-mail] (Andrew Koenig) said:
AK> Article-I.D.: alice.24699

AK> In article <[e-mail]> [e-mail] (Farshad Nayeri) writes:

> - Because of garbage collection, destructors are not as crucial in
>   Modula-3 programming. (What do you usually do in a destructor in
>   C++?)

AK> If C++ had garbage collection, destructors would sometimes still be
AK> useful.  For example, if I have an object that represents a window in
AK> my window system, I really do want the window to go away as soon as
AK> the object is no longer in use, rather than waiting around for the
AK> next garbage collection.  A similar argument applies to flushing the
AK> buffer of an I/O library structure as soon as possible.

True, see Barry Hayes's survey paper "Finalization ion the Collector
Interface" in the last International Workshop on Memory Management (Springer
Verlag LNCS 637) for a discussion of the issues.

One advantage M3 has over some of the other languages that have GC and want
finalization is that M3 has threads. This means that once the semantics of
what should be finalized is worked out the semantics of when are simple.  I
suspect that registering objects for finalization might be the easiest
semantic for determining what objects should be finalized. This could be
accomplished by passing the object to some system REGISTER_TO_FINALIZE
routine. When the GC discovers such a registered object is no longer
accessible, it passes the object to the finalization thread for finalization
sometime in the future.  Notice that finalization doesn't actually DISPOSE of
the memory used by the object it just performs actions like flushing buffers
and closing files. The GC will dispose of the memory. This solves the problem
of whether a finalization routine can resurrect an object, it can and it could
even register the object to be finalized again.

This leaves only one issue to wrap up and that is the order that linked
objects are finalized. One would not like to close a file prior to flushing
the IO buffer for example. I once thought that objects should be finalized in
reverse order of creation since this seems to follow C++ and Ada 9X
conventions. Recently, I have come to believe that this will put undo
restrictions on some GC schemes. Someone (Greg Nelson??) suggested that
one way around these restrictions is to not finalize objects that are linked.
Data structures that hold information needed for finalization would have to be
hung off of any objects that form a circularity. In other words there could be
no path from one finalizable object to another finalizable object. This seemed
like a very simple solution that would require very little rethinking of data
structures on the programmers part.

--

       Richard L. Hudson  -  [e-mail]; [phone];
       Advanced Languages Project - University Computing Services
       Lederle Graduate Research Center
       University of Massachusetts             Amherst, MA  01003
       "Unix and C are the ultimate computer viruses." - R. Gabriel