The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

443228 (2) [Avatar] Offline
#1
Hello,

Although sharing a pointer in an immutable world between actors may increase througput within a node, there are several reasons why this design decision was made in BEAM. (Note, other locations in the book spell it as "Beam", which is incorrect.)

First, it is a method of bulkheading, described prior to this section. It means that what is garbage collected is quickly collected for predictable low latency and does not require a dedicated core to continuously collect and compact Erlang process heaps. This is a problem for other functional languages such as Haskell which does not have partitioned heaps of this nature, leading to disatisfactory GC halts.

Secondly, it also relates to location transparency as discussed in section 3.4.6. By treating local and remote processes the same, the behavior and timing is predictable.

However, there is a special case for binary strings greater than 64 bytes, which are kept in a separate memory location. This means that messages will mostly only contain structure, atoms, numbers, small binary strings, and references which are small in size to copy.
Roland Kuhn (17) [Avatar] Offline
#2
443228 wrote:Hello,

Although sharing a pointer in an immutable world between actors may increase througput within a node, there are several reasons why this design decision was made in BEAM. (Note, other locations in the book spell it as "Beam", which is incorrect.)

First, it is a method of bulkheading, described prior to this section. It means that what is garbage collected is quickly collected for predictable low latency and does not require a dedicated core to continuously collect and compact Erlang process heaps. This is a problem for other functional languages such as Haskell which does not have partitioned heaps of this nature, leading to disatisfactory GC halts.

Secondly, it also relates to location transparency as discussed in section 3.4.6. By treating local and remote processes the same, the behavior and timing is predictable.

However, there is a special case for binary strings greater than 64 bytes, which are kept in a separate memory location. This means that messages will mostly only contain structure, atoms, numbers, small binary strings, and references which are small in size to copy.


Indeed, you raise good points, I’ll try to get them in!