Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Oforth : garbage collector Date: Thu, 16 Apr 2015 13:56:57 -0700 Organization: A noiseless patient Spider Lines: 29 Message-ID: <874mofiyg6.fsf@jester.gateway.pace.com> References: <022c7978-f90a-4da6-bc24-e9d252eddbcd@googlegroups.com> <87618yzk3o.fsf@jester.gateway.sonic.net> <87k2xdxhva.fsf@jester.gateway.sonic.net> <864f680d-c042-4aa4-a2bb-ede951c5997d@googlegroups.com> <8b5f2bf0-5890-4021-b54e-e559d897bde5@googlegroups.com> <878udrj1rd.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bda44be170c76b3ef6d23fecd204a8fa"; logging-data="19143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198Sz5E9ScJQSN9k3UH/RX1" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:GARMAsLYGSo2l4/mTYqg4++9gfg= sha1:SHenFDXvSsFsJsgD1NgVoEi3f7k= Xref: csiph.com comp.lang.forth:38238 franck.bensusan@gmail.com writes: > "I see a growing consensus that time-based methods... > allow more realistic timing analysis of the real-time code > Well, it seems that I have already implemented a sort of real time GC > without even knowing it... Not really, the above only makes sense in the context of incremental collectors that do a bounded amount of work at each operation. Mark-sweep is a traditional stop-the-world algorithm and doesn't fit this picture. > I will study this more precisely , particulary their Metronome algorithm. Perry Cheng's PhD thesis is pretty readable, if you can find it online. Here's a paper by Cheng and Blelloch that is probably an overview: http://www.cs.cmu.edu/~blelloch/papers/gc2001.pdf The cool trick is being a parallel real-time GC and I think Metronome related but newer and fancier. But, single-threaded real-time GC has existed for a long time, e.g the Baker treadmill: http://home.pipeline.com/~hbaker1/NoMotionGC.html It might be possible to just write the real-time parts of your program to do no allocation, then run them in separate tasks with guaranteed time slices, so no GC at all need be run in them. I think I've heard of some robotics stuff programmed that way in Scheme.