[gclist] Re: gclist-digest V3 #84

[Richard A. O'Keefe]

	> Erlang *doesn't* get pointers to the heaps of other threads,
	> *doesn't* have to, and *does* have excellent reason not to use
	> separate address spaces.
	
	The reason being a shared global heap, apparently.  So it's not
	a pure per-thread heap system.  Presumably, allocation in the
	global heap needs synchronization, but it's rare?

As I've explained already, Erlang includes a datatype called
"binaries".  Erlang is intended for implementing/managing telecoms
applications, for example there's a scalable ATM switch (10-160 GB/s)
controlled by 300 kSLOC of bought-in C and 300 kSLOC of Erlang.
If you receive an 8kB packet, you probably don't want to copy it too
often.  The great thing about binaries is that they do not contain any
pointers, so you don't need a general purpose garbage collector to
handle them.  I don't know what Erlang actually uses (there have been
several Erlang implementations) but a reference counting scheme where
the counts out of a thread's heap are decremented by that thread's GC
would work, as would other schemes.  Reference count activity would be
rare because the number of references _within_ a thread would not
matter, only whether it was 0 or 1.  There _would_ be locking, but
the locking would be rare and could be per-binary.

Erlang's "atoms" (Lisp like symbols, but without any properties) are
also shared read-only objects with no outward pointers, and can be
treated the same way.  Since Erlang supports "hot loading", executable
code needs and can get similar treatment.  Hot loading would of course
be fairly rare (once a day rather than once a millisecond).

	<URL:http://www.cs.utexas.edu/users/emery/hoard/>
Thank you.