Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
From: Des.Kenny@bbs.actrix.gen.nz
Date: Tue, 29 Sep 1992 10:44:19 GMT
Organization: Actrix Information Exchange
Keywords: Garbage collection, incremental, real time, Eiffel
Summary: Garbage collection in real time applications				 

In article <#qjz+#j@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
> 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).
  
  I think that I have a slightly different view of garbage collection.
  I prefer the preventative approach rather than the curative approach.
  But of course cures must be available as a last resort. But not as
  a first resort.

  Eiffel's incremental garbage collector is designed to clean the garbage
  BEFORE you run out of memory for an application , rather than after you have
  already run out. 

  You can turn on thr garbage collector for an application and let it
  operate completely automatically, which may be the best option in many
  cases.

  Or you can tune it by inheriting from the
  class MEMORY, where the tuning capability resides.

  Many applications will operate fine by allowing the garbage collector
  to run with the default system parameters. Garbage collection is then barely
  an issue at all.

  However, Eiffel does allow you to tailor garbage collection for specific
  classes if you wish. Clearly it is up to the person using this facility to 
  know what the load is on the system and be aware of what memory , I/O ,
  processor and other resources are available in such an environment
  when the tunable class is running. This will involve a degree of
  calibration.

  Such a case may be a real time embedded system, where the parameters
  of the system, boundary conditions, are reasonably precisely defined.
  So the system load is not too difficult to predict. It will again vary
  with individual cases.

  Eiffel is being used in one such instance by Advanced Robotics Research Ltd
  in the U.K. They are building a mobile robot weighing 1/3 of a ton.

  The system has to respond at the 20ms level.

  It is a safety critical application. A runaway 1/3 of a ton robot is
  no joke! 

  It is using four T800 Transputers and two datalinks that have transfer rates
  of 200MB/second.
   
 
  So this is real time with Eiffel. I do not know how exactly
  they are using the garbage collector. I will let you know when I find out.
  But you can be sure that they can not afford a memory seizure of a mobile
  1/3 ton beastie!

  They have a spectrum of choices from no garbage collection, to tuned
collection to full system default collection. It will be very interesting to
see how they are approaching this issue.
 
> 
> Consider the following scenario:
> 	Suppose that there are real time constraints and the
> 		user wants to control when garbage collection can and cannot
> 		occur.

        As I said above the user must know the load profile on the system.
        This applies to any kind of tuning you care to  do on any system.
        Every case is different. So you have to tune your applications in
        the context that they are going to be used, including the system
        resources available.
 
> 	Now the application programmer needs to determine if and when the set of
> 		active jobs will use all available memory.
        
        You are clearly going to have to calibrate your applications in a
        given context.  Also we should aim for prevention rather than cure.
        So a margin of error is wise in calculating memory required.
        Then it is a matter of switching on the garbage collector at suitable
        intervals to do PARTIAL collection. Note that this is not a full
        collection. We are trying to prevent the application from running out
        of memory before we get too close to the critical margin of error.

> 	This seems unreasonable, as Eiffel does its own allocation/deallocation
> 		stuff under the hood (that is transparently to the user).

        This will have to be allowed for in the calibration.

> 	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).

        Not if you allow a margin of error and initiate partial collection at 
        frequent enough intervals.

> 	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.


        Not if you have calibrated the application in a given context of
        other applications and system resources; and allowed a sufficient
        error margin; and have partial collection at frequent enough
        intervals.
      
        Different applications in different contexts will use memory
        with different profiles of usage. You can not always predict these
        profiles but you can run sufficient cases to allow a safe
        margin of error to be used. The cost of memory is no longer
        such an issue, so you can err on the side of memory that
        accounts for the margin of error.

        Well it is not perfect but then you are asking for applications
        to run at the limits of the systems resource capabilities.
        So you have to provide enough resources to allow for the
        imperfection in our ability to predict exactly what is
        needed. This is by no means a new strategy in any system
        context, OO or otherwise. Operating systems can thrash
        if they are out of balance in terms of load and resources
        such as memory and disk, for example.

        It is going to extremely interesting to see how ARRL
        handle this situation.
        
        
 --Des Kenny
   Objective Methods Ltd
   PO Box 17356
   Wellington
   New Zealand
   phone: 64 4 476 9499
   fax  : 64 4 476 9237
   email(Internet): Des.Kenny@bbs.actrix.gen.nz