From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,df05246395602224 X-Google-Attributes: gid103376,public From: hbaker@netcom.com (Henry Baker) Subject: Re: Variable-block memory managers bad in realtime Date: 1998/01/01 Message-ID: #1/1 X-Deja-AN: 311901095 Content-Transfer-Encoding: 8bit Sender: hbaker@netcom10.netcom.com References: Content-Type: text/plain; charset=ISO-8859-1 Organization: nil Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-01T00:00:00+00:00 List-Id: In article , Jon S Anthony wrote: > gwinn@res.ray.com (Joe Gwinn) writes: > > Will do. Do you have more specific references? Thanks. > > We are doing the equivalent of engine control in many places. > > If that's really true (with cycle times measured in microseconds), > this stuff isn't going to work for you. Well, it depends upon what you mean by 'this stuff'. Well-engineered dynamic storage algorithms can be used for hard real-time applications, but they do have to be designed for this purpose. A number of 'multi-media' systems with hard real-time requirements have been built using real-time GC techniques. Most dynamic storage allocators -- including nearly all implementations of 'malloc' -- have not been designed for hard real-time use. Most mallocs have been designed to make the standard benchmarks run fast (if even that!) and probably have to be replaced for many serious applications. There have been some very interesting measurements of the 'standard' mallocs that ship with various operating systems, and they aren't pretty. So the problem isn't _GC_, per se, but non-real-time allocators themselves. A number of people in the GC community are interested in embedded systems applications of GC. Do a web search for Kelvin Nielsen.