[erlang-questions] Why are messages between processes copied?

[Masklinn]

On 2012-02-23, at 10:58 , Thomas Lindgren wrote:
> ----- Original Message -----
>> From: Masklinn <masklinn@REDACTED>
>> To: Lukas Larsson <lukas@REDACTED>
>> Cc: Erlang Questions <erlang-questions@REDACTED>
>> Sent: Thursday, February 23, 2012 9:46 AM
>> Subject: Re: [erlang-questions] Why are messages between processes copied?
>> 
>> On 2012-02-23, at 09:22 , Lukas Larsson wrote:
>>> Not sure what you mean by moving structures as opposed to copying?
>> 
>> Currently the content of the message is copied from one process heap
>> to the next, in the case of local messages, correct?
>> 
>> If the runtime knew the message (and its components) is not re-used
>> after sending it, it could *move* the whole message from one heap to
>> the next skipping the copy step (but needing to cooperate a bit with
>> the GC I guess, in order to invalidate the local pointer in the
>> origin process).
> 
> I think Richard Carlsson et al tried something similar, which I recall as follows (sorry if it's garbled): allocate data that may be sent in a global heap, while definitely private data goes in the local heap of the process. Classify the data using static analysis. Message sends then become pointer management rather than copying. I'm not sure of the outcome, percent gained etc.

That's a bit different, what I talk about isn't semantically shared
heaps (although it could be implemented as such).

> None of these attempts (as well as others with shared or hybrid heaps, available in older OTP distros) seem to have really taken root. At a guess, the current runtime system does well enough on "normal programs" that we're sufficiently well-off as we are. In a previous life and for a previous runtime system, we measured that message passing _might_ become a practical bottleneck if the sequential runtime system (using Hipe) was 2x faster or so. I suspect this factor may have increased in the meantime due to various OTP hacks.

Yeah that's about what I'd expect as well, these approaches could work
if the static analysis was easy and the behavior was easy to understand
(which is what they're trying with Rust), otherwise it's just an (often
minor) optimization.