[erlang-questions] A whole bunch of implementation details
Thu Sep 4 09:17:23 CEST 2008
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?
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?
More information about the erlang-questions