From: ac690@cleveland.Freenet.Edu (Edward Klimas)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Date: 29 Sep 1992 05:53:50 GMT
Organization: Linea Engineering Inc, Cleveland, OH (USA)
Reply-To: ac690@cleveland.Freenet.Edu (Edward Klimas)
NNTP-Posting-Host: slc4.ins.cwru.edu


In a previous article, maniattb@cs.rpi.edu (Bill Maniatty) says:

>In article <1992Sep29.011914.10172@actrix.gen.nz>, Des.Kenny@bbs.actrix.gen.nz writes:
>|> In article <+s_p3w=.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
>|> > Bob Hathaway <objsys@netcom.com> writes:
>|> > >In article <8mgztqf@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
>|> > >>On the flip side, I'm under the impression that real time programming cannot be
>|> > >>done with a Garbage Collecting language, as the garbage collection could
>|> > >>happen at an arbitrary time, and cause a violation of the timing constraints.
>	[Stuff Deleted]
>|> Since 1976 when the first Eiffel compiler was released it has had tuneable 
>|> garbage collection. The version from ISE ( the original ) allows you to turn
>|> garbage collection off for time critical classes. The garbage collector in
>|> ISE's version of Eiffel operates as a coroutine anyway. It is an incremental
>|> garbage collector operating in small bursts rather than taking over the whole
>|> system to clean the mess. The class MEMORY has features to control the
>|> interval of collection. You can turn collection on or off and do partial 
>|> garbage collection.
>|> 
>|> So you can tune the collection for real time
>|> applications to when the resources are available for collection and not impact
>|> time critical method operations. This is not new. It has always been there in
>|> Eiffel since the first release.
>
>This does not seem safe, (I wish this weren't true).  The whole point of garbage
>collection is that when the system is out of memory, it can check the allocated
>memory to see which parts of the heap are allocated but unreferenced (and
>therefore garbage).
>
>Consider the following scenario:
>	Suppose that there are real time constraints and the
>		user wants to control when garbage collection can and cannot
>		occur.
>	Now the application programmer needs to determine if and when the set of
>		active jobs will use all available memory.
>	This seems unreasonable, as Eiffel does its own allocation/deallocation
>		stuff under the hood (that is transparently to the user).
>	In that case the only alternative is for the system to detect and handle
>		the exception (that is interrupt when the ``out of memory''
>		condition occurs).
>	This could occur at a time not anticipated by the user.
>	The user has disabled the garbage collector from running at this time
>		however and the system locks up.

	Take a look at the proceedings of the 1990 OOPSLA Workshop
	on Real-Time OOP.  The Baker-Lieberman(?) GC algorithm is discussed
	which permits deterministic real-time GC.  (e.g.among other things, 
	you can say I have x amount of time available, do as much GC as you 
	can in that time and finish up so that the system will be ready for 
	the next real time input)

	Ed Klimas

>|> Des Kenny
>|> Objective Methods
>
>Bill Maniatty
>-- 
>|
>|	maniattb@cs.rpi.edu - in real life Bill Maniatty
>|
>