Re: Oforth : garbage collector

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 <no.email@nospam.invalid>
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> (permalink)
References	<022c7978-f90a-4da6-bc24-e9d252eddbcd@googlegroups.com> <87618yzk3o.fsf@jester.gateway.sonic.net> <ffc3f8f1-2e1e-4ce8-8d99-c7076b90fe71@googlegroups.com> <87k2xdxhva.fsf@jester.gateway.sonic.net> <864f680d-c042-4aa4-a2bb-ede951c5997d@googlegroups.com> <8b5f2bf0-5890-4021-b54e-e559d897bde5@googlegroups.com> <b4388167-ae01-4aaf-b904-23b7617fb22b@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

Show key headers only | View raw

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.

Thread

Oforth : garbage collector franck.bensusan@gmail.com - 2015-04-13 13:43 -0700
  Re: Oforth : garbage collector Paul Rubin <no.email@nospam.invalid> - 2015-04-14 10:38 -0700
    Re: Oforth : garbage collector franck.bensusan@gmail.com - 2015-04-14 14:17 -0700
      Re: Oforth : garbage collector Paul Rubin <no.email@nospam.invalid> - 2015-04-15 13:21 -0700
        Re: Oforth : garbage collector hughaguilar96@gmail.com - 2015-04-15 14:04 -0700
          Re: Oforth : garbage collector Mark Wills <markwills1970@gmail.com> - 2015-04-16 00:57 -0700
            Re: Oforth : garbage collector franck.bensusan@gmail.com - 2015-04-16 10:42 -0700
              Re: Oforth : garbage collector Paul Rubin <no.email@nospam.invalid> - 2015-04-16 12:45 -0700
                Re: Oforth : garbage collector franck.bensusan@gmail.com - 2015-04-16 13:27 -0700
                Re: Oforth : garbage collector Paul Rubin <no.email@nospam.invalid> - 2015-04-16 13:56 -0700
                Re: Oforth : garbage collector franck.bensusan@gmail.com - 2015-04-19 11:43 -0700
                Re: Oforth : garbage collector Paul Rubin <no.email@nospam.invalid> - 2015-04-19 20:38 -0700

csiph-web