Re: Garbage collection and quality of implementation issues

adobe!mhamburg@uunet.UU.NET (Mark Hamburg)
Sun, 29 May 1994 07:20:11 GMT

          From comp.compilers

Related articles
Garbage collection and quality of implementation issues mps@dent.uchicago.edu (1994-05-25)
Re: Garbage collection and quality of implementation issues boehm@parc.xerox.com (1994-05-26)
Re: Garbage collection and quality of implementation issues jgmorris+@cs.cmu.edu (1994-05-26)
Re: Garbage collection and quality of implementation issues mps@dent.uchicago.edu (1994-05-27)
Re: Garbage collection and quality of implementation issues mw@ipx2.rz.uni-mannheim.de (1994-05-27)
Re: Garbage collection and quality of implementation issues jgmorris+@cs.cmu.edu (1994-05-28)
Re: Garbage collection and quality of implementation issues adobe!mhamburg@uunet.UU.NET (1994-05-29)
| List of all articles for this month |
Newsgroups: comp.compilers
From: adobe!mhamburg@uunet.UU.NET (Mark Hamburg)
Followup-To: comp.compilers
Keywords: GC
Organization: Adobe Systems, Inc.
References: <94-05-105@comp.compilers1> 94-05-126
Date: Sun, 29 May 1994 07:20:11 GMT

While we're on the subject of garbage collectors and finalization,
consider the following:


I have some objects representing indexes into a text stream. When I
insert and delete from the stream, I want to update the indices. This
means I need to keep track of all of the indices and a linked list makes a
very nice data structure for doing so. (If I store the pieces of the text
stream in a linked list, I can meld the two lists and get the updating for
free!)


Now, the problem is that I would like these index objects to be garbage
collected for all the usual reasons. They are, however, linked into this
data structure that I definitely want to keep around and hence are not
garbage.


What I need is some way to get them to unlink when the last reference from
outside the structure disappears.


The best approach I have though of is to have two kinds of pointers. I
would call them strong and weak but those already have different though
related meanings in the field, so let's call them red and blue.


I link the index objects into the text stream using blue pointers but I
refer to them from outside the text stream using red pointers.


An object is only collected when there are no more pointers to it (of
either color). Collection at this time simply reclaims memory without
invoking any programmer supplied code.


When the garbage collector detects that there are no red pointers to an
object, it calls a programmer defined method for the object. This method
can take the appropriate actions to unlink the object. Invoking this
method is potentially fraught with all the usual concerns about methods
being invoked at surprising times.


This sort of thing certainly won't work without linguistic support.


It is also relatively complicated and imposes a burden on the programmer.


If anyone has a better idea, I would love to hear it.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.