[gclist] Re: gclist-digest V3 #84

[Richard A. O'Keefe]

	The difficulty comes when threads get pointers to the heaps of other
	threads (as they must; if you weren't sharing memory between threads,
	you'd use separate process spaces, stop tearing your hair out, and
	spend more time with the wife and kids).

This is language-dependent.  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.

	In the extreme case, a
	producer-consumer thread pair can consume unbounded memory if the
	consumer can't get access to the producer's freelist, and instead
	squirrels all the dead memory away uselessly in its own.

In Erlang, the producer creates a data structure and sends it to the
consumer.  The mechanism of sending is such that a copy arrives in the
message queue of the consumer.  That copy is owned by the consumer,
which couldn't care less if the producer immediately dropped dead and
had all its bits swept up and recycled.  The producer's copy is now dead,
but the copy that is dead is in the producer, to be reclaimed by the
producer's gc.  When the consumer has finished with its copy, the memory
is reclaimed as part of the consumer's heap, not the producer's.

In fact, a really smart Erlang implementation could eliminate some of the
intra-node copying.  Here's one message send out of some Erlang sources I
happen to have handy
%   PID  ! MESSAGE
    From ! {self(), node(), 'Logger stopped'},

This could be implemented as
	r1 := self()		-- current PID
	r2 := node()		-- this node name
	r3 := 'Logger stopped'	-- pointer to global binary pointerless object
	r0 := From
	r4 := get_receiver_message_space(r0, 4)
	r4[0] := tuple/4 tag
	r4[1] := r1
	r4[2] := r2
	r4[3] := r3
	finish_send()
where the receiver's message queue would be locked, space allocated in it,
and filled in, then the message finished and the lock released.  Since the
amount to be filled in would be bounded by what was known about the value
at compile time, the lock would be held for a small bounded amount of time.

Most Erlang messages are either fairly small or carry the bulk of the data
in global binary pointerless objects, so most of the actual copying could
be eliminated.

The details don't matter, what does matter is that just because something
has the semantics of a copy doesn't mean it has to be implemented as a copy.

	The Hoard paper shows an efficient implementation

Reference?