Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #38206
| 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> |
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
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