[erlang-questions] A whole bunch of implementation details

[Mikael Pettersson]

Dennis Byrne writes:
 > Gave a presentation today to a very bright crowd.  Lots of these people 
 > just wanted to ask questions rather than looks at slides.  Here's a 
 > handful of questions I got, for which I was anywhere from half way to 
 > completely clueless on. 
 > 
 > Does a process get pinned to one OS thread for it's entire existence? What 
 > factors go into the VM's decision to pin a process to one OS thread or 
 > another?  How do we prevent all the busiest processes from being tied to 
 > one OS level thread? 

An Erlang process isn't pinned. The Erlang schedulers themselves are
unpinned threads that fetch Erlang processes from a common queue.
(At least the queue was common last time I looked.)

 > How does stack memory grow?  Am told Prolog does this dynamically and I 
 > was wondering if Erlang did the same.

Dynamic overflow check, followed by reallocation/copy in the overflow case.

 > Does heap memory contract? 

Logically, yes.
Pages allocated from the OS kernel may or may not be released back to
the kernel. I think (haven't looked in detail) that freed pages are kept
by the Erlang runtime for future use.

 > Exactly what is the tipping point between what gets passed by value and 
 > what gets passed by reference?  The large binary trick is common 
 > knowledge, any other corner cases?

Function calls are pass by reference.
Sends are pass by copy, except for largish binary blobs which
are allocated off-heap, reference counted, and passed by reference.
(Well, a small handle is passed by copy.)

 > How does the VM differentiate between a node that is temporarily 
 > unresponsive and one that is down?  In other words, at what point does a 
 > node give up on a peer?

Dunno.

/Mikael