Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.eiffel
Subject: Re: comparing object-oriented platforms
From: Des.Kenny@bbs.actrix.gen.nz
Date: Tue, 29 Sep 1992 22:36:29 GMT
Organization: Actrix Information Exchange
Summary: Real time requires a wide systems view 

In article <TMB.92Sep29174712@arolla.idiap.ch> tmb@idiap.ch writes:
> 
>      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.
> 
> Assume I have a program that never has more live data than, say, 45%
> of real memory. Does your Eiffel implementation guarantee that every
> request for memory has a small bounded latency, and does it guarantee
> at the same time that my program will never run out of memory?
> 
  If you turn off the garbage collector you risk running out of
  memory. You have to calibrate this particular application
  in a given context.

> I am all for GC, even in real-time applications. Furthermore, you can
> do real-time GC "right", meaning, you can guarantee (small) bounded
> latencies for all operations that would have bounded latencies in the
> absence of GC.
> 
  This is going to depend on the application and the resources
  in a particular context. You have to allow enough hardware
  to compensate for the fact that you can not make a perfect
  prediction of exactly what resources are going to be required
  during the entire run time of an application.

   

> isn't getting it right. "Turning off GC" means that you will
> potentially run out of memory, which is probably even more dangerous
> than garbage collecting for a little while.
 
  Yes. I was merely saying that this is an option on the spectrum
  of choices for any application. In real time it would be clearly
  an undesireable choice. 

> "Tuning your application"
> means that you are hacking around without knowing whether your code
> actually has a bounded latency.

  I am not sure why you say this. If you calibrate the application
  in a context of resources available you would be able to
  measure resources consumed over time and time delays in response
  to requests for system resources.

  If you have calibrated these resource usages and response delays
  and you have allocated sufficient hardware to account for
  the extreme cases, I am not sure that there is an unsolvable
  problem here.

  You can then decide when are the best times to do partial garbage
  collection and how long the collection interval should be.

  I never said this was easy. But then real time is not easy.
  
> So which is it? If there were a commercial implementation of a
> real-time GC for a general purpose language, I'd definitely like to
> know about it.
  
  I suggest you contact ISE for the details of the GC in the
  new version of Eiffel (3.0).  I do not know what SIG is doing
  about this. Sather from Berkley has been targetted at real time.
  It is a derivative of Eiffel. I do not know exactly how they are
  handling GC.
 

 Otherwise, Eiffel doesn't seem to be any more suitable
> than run-of-the-mill CommonLisp implementations for real-time
> programming, which have lots of facilities for "tuning". In fact,
> using facilities such as weak references and pools, I suspect that a
> run-of-the-mill CommonLisp implementation might even be better suited
> (relatively speaking) to real-time programming than Eiffel.

  There are other reasons why CLOS does not suit my requirements.
  It is too unsafe in its class interface: you can not restrict
  access to attributes ( state ) to methods of the class.

  So any other class can get into the state and alter it, by-passing
  the OO principle of only allowing access via a classes own methods.

  Also static type checking is not enforced. I prefer static type
  checking for large scale industrial applications. I do not want to discover
  a type error at run time! There are some applications such as small scale
  prototypes/experiments/research where static type checking is not a
  significant issue. However, in the industrial setting we need all the help
  we can get from the tools to reduce the error rate in systems with finite
  budgets and impatient users. Now these are REAL resource constraints
  in industry.


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



   
	


Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA