Each process is a Pharo object (an instance of ERringElement) that contains a counter, a reference to the next ERringElement, and an "ErlangProcess" that is a Process that contains a reference to an instance of SharedQueue (its "mailbox").
The good news is that up to 50k processes, it didn't crash. But it did run with increasing sloth.
I can imagine that the increasing process-creation time is due to beating on the memory manager. But why the increasing message-sending time as the number of processes increases? (Recall that exactly one process is runnable at any given time). I'm wondering if the scheduler is somehow getting overwhelmed by all of the non-runable processes that are blocked on Semaphores in SharedQueue. Any ideas?
If you're using Cog then one reason performance falls off with number of processes is context-to-stack mapping, see 08 Under Cover Contexts and the Big Frame-Up. Once there are more processes than stack pages every process switch faults out a(t least one) frame to a heap context and faults in a heap context to a frame. You can experiment by changing the number of stack pages (see vmAttributeAt:put:) but you can't have thousands of stack pages; it uses too much C stack memory. I think the default is 64 pages and Teleplace uses ~ 112. Each stack page can hold up to approximately 50 activations.
But to be sure what the cause of the slowdown is one could use my VMProfiler. Has anyone ported this to Pharo yet?
not that I know. Where is the code :)
(My code is on Squeaksource in project Erlang. But be warned that there is a simulation of the Erlang "universal server" in there too. To run this code, look for class ErlangRingTest.)
-- best, Eliot