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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public From: Ken Garlington Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/17 Message-ID: <33CEA6AC.3566@flash.net>#1/1 X-Deja-AN: 257525244 References: <33C56F97.1223@gsfc.nasa.gov> <5qc53v$kb6@alumni.rpi.edu> <33CBF5DE.D5FB1B6C@munich.netsurf.de> Organization: Flashnet Communications, http://www.flash.net Reply-To: kennieg@flash.net Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-17T00:00:00+00:00 List-Id: Joachim Durchholz wrote: > > 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). How does GC run "in parallel" on a uniprocessor implementation? I assume you mean that it can be run in a separate process, but that's not a concern. More interesting questions to ask about these algorithms are (for example): 1. What is the longest "critical section" (a section that cannot be pre-empted) within these GC algorithms? 2. If the GC process is given the lowest priority, how long can it be "starved" before memory allocation problems occur? 3. If the GC process is not given the lowest priority, what is the likelihood that a lower priority process will be starved? 4. How much overhead will be used in swapping this process in and out sufficiently often to keep sufficient memory available? > > > Modern GC presumably can get around that problem, > > That reads "definitely", not "presumably". The algorithms are there. > Besides, hand-crafted GC may look nice on paper, but it's usually less > efficient than automatec GC. > Manual deallocation means programmers will pass around more copies of > objects, defeating the very reason why automated GC isn't used. (The > reason is that, if the programmer would just pass the reference, the > owner of the object has to worry wether that reference he gave aways is > still in use somewhere. If the object is copied, the owner can > deallocate the original and doesn't have to worry about the copy - but > the copying process itself may be more machine cycles than what would > have been necessary to reclaim the single object with automated GC.) > > > but the purveyors > > presumably can't prove its efficacy and response time to the > > satisfaction of the FAA and other safety hard-noses. > > Well, I'm feeling cynical today, so I'd say that the safety gurus just > don't know or care about the algorithms, because it's something new and > they'd have to *think*. (There is a surprising number of non-engineers > in any bureaucratic body.) Or, perhaps the people have enough problems analyzing time effects in a safety-critical system to have to worry about another process, one with potentially variable effects depending upon heap utilization at different points in the program. > > Regards, > Joachim > -- > Please don't send unsolicited ads.