Why didn't they do GC per process like Erlang instead of GC per thread?
I thought processes and sub processes are cheaper to spawn then threads? That's the reason why Chrome tabs are in per sub processes right? Instead of threads?
Firstly, while I'm not very familiar with Erlang or its runtime, afaik Erlang processes are not actual OS processes.
Secondly threads were originally created as a cheaper alternative because spawning processes was too expensive (on Windows). The original reason for Chrome using processes was that processes gives you memory protection. But I don't know how much it really helped them in the end, because they quickly noticed that using one process per tab doesn't scale. Thus Chrome (at least originally) limited the maximum number of processes to ten.
Rust actually has multiple heaps with their own lifetime characteristics so that they can avoid GC in many cases, and that the only GCed areas are per-thread.
The costs of threads vs processes are identical if you're prepared to put some stuff in virtual memory (except on Windows, and I don't know if that has improved). Processes default to full isolation, threads are the reverse, but Rust has enough compile-time guarantees that it can do its own isolation for most purposes. I imagine they could go back and forth on this one without breaking source compatibility.
GC per lightweight thread does not imply stop-the-world approach as in Go.
Also process is heavier entity for OS kernel in comparison to thread (address space, file descriptors are all per-process objects, not per-thread, thread is just a unit of processor time scheduling). Chrome tabs are processes for security reasons. Chrome trades speed for security in this context.
I thought processes and sub processes are cheaper to spawn then threads? That's the reason why Chrome tabs are in per sub processes right? Instead of threads?