Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.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 12:45:26 -0700 Organization: A noiseless patient Spider Lines: 22 Message-ID: <878udrj1rd.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bda44be170c76b3ef6d23fecd204a8fa"; logging-data="31566"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9TE3vqtndJbvzj1LsD6zN" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:XiCDDVhpXxZw3RicYDBcZJTX3yU= sha1:NcA+kxYt9CtM38RaLAlbPTMRLNw= Xref: csiph.com comp.lang.forth:38236 franck.bensusan@gmail.com writes: >>In a lightweight tasking system this will burn lots of cpu, since the >>tasks will usually be idle, waiting on i/o. > > Sorry, Paul, but I don't understand this. If no new objects are > allocated, why GC would burn cpu : it will run quicker, that's all. It's a mark-sweep collector so you have to trace all the live objects even if no new ones have been allocated. So the usual strategy is to gc after some given amount of allocation, rather than some given amount of milliseconds. There are real-time gc algorithms that aren't that horribly complicated. If your goal is to guarantee latency bounds, implementing a realtime gc sounds like the right approach. Maybe you could also reconsider the Erlang approach of copying objects between processes. Besides minimizing gc latency (by letting you run separate gc's per thread), it also lets you distribute applications across multiple machines. Maybe the Oforth compiler could even target the Erlang virtual machine. There are already a couple of other languages (Elixir and LFE) that target it.