Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #38206

Re: Oforth : garbage collector

From Paul Rubin <no.email@nospam.invalid>
Newsgroups comp.lang.forth
Subject Re: Oforth : garbage collector
Date 2015-04-15 13:21 -0700
Organization A noiseless patient Spider
Message-ID <87k2xdxhva.fsf@jester.gateway.sonic.net> (permalink)
References <022c7978-f90a-4da6-bc24-e9d252eddbcd@googlegroups.com> <87618yzk3o.fsf@jester.gateway.sonic.net> <ffc3f8f1-2e1e-4ce8-8d99-c7076b90fe71@googlegroups.com>

Show all headers | View raw


franck.bensusan@gmail.com writes:
> Oforth doesn't really have process isolation.
> Each thread has indeed a separate heap but objects can be shared
> between tasks the threads are performing.

Hmm, ok, I didn't realize that.  Erlang's implementation actually shares
large strings ("binaries") between processes: they are refcounted
instead of GC'd, which works ok since they don't contain pointers.
There is also Erlang Term Storage (ETS) which are shared through some
comparable implementation hack.  In both cases from the client code's
point of view, nothing is shared (the API is the same) but the
implementation gets to make some short cuts. 

> Erlang deals process isolation by copying messages between processes. I
> have never liked this. It is, imo, a waste of time and memory.

It's generally small stuff that's copied and the cpu usage is small.

> In Oforth,... objects references are sent between tasks, without
> copying anything.  A mutable object, on the other hand, is isolated
> into the task that created it.

Hmm, ok, that means the gc heaps can't be separate between tasks though.
Fair enough.

> Another thing is that an Erlang process will run GC only when it
> reaches an amount of allocated memory. I don't like this either.  I
> prefer a GC running every 120ms to keep memory allocation as small as
> possible.

In a lightweight tasking system this will burn lots of cpu, since the
tasks will usually be idle, waiting on i/o.

> But it could be an option to run GC only if an amount of memory
> allocated is reached. Have to think about it :)

That's how every system I've ever seen does it.  There are some realtime
GC schemes that do a little bit of GC with every allocation, but even
that's not on a fixed timer.  

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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