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: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: jsa@alexandria.organon.com (Jon S Anthony) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/18 Message-ID: #1/1 X-Deja-AN: 257543220 Distribution: world References: <33C56F97.1223@gsfc.nasa.gov> <5qc53v$kb6@alumni.rpi.edu> <33CBF5DE.D5FB1B6C@munich.netsurf.de> Organization: PSINet Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-18T00:00:00+00:00 List-Id: In article <33CBF5DE.D5FB1B6C@munich.netsurf.de> Joachim Durchholz writes: > Steve Furlong wrote: > > get or free memory. If your process _must_ check ports every 10 ms, > > you can't be waiting half a second for memory compaction. > > Arrgh! Will that idea nevere go away!! > The best available GC algorithms don't go away for compacting; they run > in parallel with the normal program (as a coroutine if you don't want a > preemptive scheduler). Well, I'm certainly a GC supporter (as many here know only too well :-), but there's more to this than a simplistic "yes it can" "no it can't". First, compacting may well have nothing to do with it. What compacting are you talking about? The sort that you get for "free" in a copying collector? Or do you really mean a compacting MS style collector? Even generational variants of the former will likely suck up _way_ too much memory for the sort of application that Steve is talking about. And for the latter, true compaction activity interwoven with mutator activity is non-trivial. The techniques would be closer to incremental or true concurrent collectors. Now, these latter are _claimed_ to be sufficient in _some_ real time scenarios. But, a) this is typically predicated on some sort of HW support for the GC, and b) even then, the sort of time constraints Steve is talking about seem implausible given the current evidence. Given the sort of application Steve seems to be talking about, I don't think that current GC could guarantee things and besides, it probably wouldn't buy you that much anyway - it's not likely that the structures involved in the sort of program indicated would be highly interwoven, which is when manual deallocation becomes extremely burdensome and highly error prone (maybe outright impractical). > That reads "definitely", not "presumably". The algorithms are there. Highly unlikely given the sort of setting Steve seems to have in mind. Think of an ECU where the 10ms time limit is the hard limit on the evaluation loop and every cycle available in that time limit is used up by "real" work. /Jon -- Jon Anthony OMI, Belmont, MA 02178 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari