Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!psuvax1!brutus.cs.uiuc.edu!ginosko!uunet!mcsun!ukc!cam-cl!scc From: scc@cl.cam.ac.uk (Stephen Crawley) Newsgroups: comp.sw.components Subject: Re: Real-time Garbage Collection Message-ID: <910@scaup.cl.cam.ac.uk> Date: 25 Sep 89 08:38:36 GMT References: <901@scaup.cl.cam.ac.uk> <6554@hubcap.clemson.edu> Sender: news@cl.cam.ac.uk Organization: U of Cambridge Comp Lab, UK Lines: 101 I wrote: >> Bill Wolfe proposes a scheme for getting around the need for garbage >> collection by storing objects in a database, using object expiration >> times to avoid proper garbage collection. Unfortunately this scheme >> doesn't achieve its aim. >> >> "Where objects can have an infinite lifetime, a protocol can be devised >> whereby the database must be checked at least once per some arbitrary >> time period by all users, which will permit identification numbers >> to be recycled after one full time period of nonexistence." >> >> Exactly. In order to check each object that it still refers to, each >> "user" (actually application) must traverse the graph of its objects in >> the database. This process is exactly equivalent to the mark phase of >> a garbage collection, except that the application is doing it!!! Bill Wolfe replies > Not exactly. To start with, the user does not have to do any work > at all if the identification number's expiration period is also used > as the period over which the user will lose interest in the object if > it is not further utilized. In this case, the identification number > will be allowed to expire and the user need only throw it away. In other words the objects don't have a long lifetime. This is a red herring!! The case we were discussing is the one where the objects DO have long lifetimes. Bill continues: > If the user does make use of the number within the expiration period, > then the number is automatically revalidated for another period ... Granted. But unless there is a GUARANTEE that EVERY object of interest is touched periodically by the application, there is a risk that objects of interest to the user will be destroyed prematurely. > ... unless the database replies that the object has been destroyed, > in which case the identification number expires as well. From the user's point of view, this is unacceptable behaviour by the application / database cabal. Bill continues: > In the worst case, the user will have to do a database access just to > verify that the object still exists and that the identification number > remains valid for another expiration period. Since many objects have > a finite lifetime, this burden is borne only by those users who make > use of infinite-lifetime objects. Not true. There is no way for an application to intuit the lifetime of a given set of database entries. If it makes a guess, and is wrong it has committed the sin of destroying user data. We can't expect the user to specify an accurate lifetime either. The user can't accurately predict the future any more than an application can. It would be totally unreasonable to then come back to a user and say "21 of your objects expired and were deleted. Oh, you didn't want that? Well tough." In this day and age, users are more and more naive, and systems must be correspondingly forgiving. Therefore, the burden of storage management must be borne by ALL applications that deal with POTENTIALLY long lived data items. In practice this means ALL applications that store data in the database. Bill continues: > The task of maintaining the validity of the identification number can > be done automatically if desired using a suitably designed identification- > number abstraction which carries a user-settable automatic revalidation > on-off switch. I'm not sure, but this sounds like Bill is finally admitting that the application needs to include a GC style marker. However ... user-settable object refreshing is like giving a hang grenade to a two year old. I can just imagine it now: User: I came in this morning and half of my PC's database has disappeared Support: Hmmm ... why is object refresshing turned off??? User: Joe told me that turning off object would make the database would make it go faster. Bill continues to describe an object access control scheme, which is pretty much beside the point ... I wrote: >> One other point that Bill Wolfe misses is that the CPU overheads of >> managing objects in this way can be orders of magnitude greater >> than the cost of using ordinary pointers. Bill replies: > We are managing objects in this way because they present worst-case > properties which do not permit us to use more efficient techniques. What about garbage collection??? Surely Bill's scheme with object numbers and expiration times and (as Bill finally admits) object refreshing in application code is MUCH MORE EXPENSIVE than an efficient garbage collector! Bear in mind that a previous article (sorry no ref.) claimed measurements of overheads of only 3-5% for a modern garbage collector. -- Steve