Still, separating processes merely to address heap fragmentation looks like a huge overkill (and a waste of other resources too). A much better way would be to take over control of memory allocation, for example using Boost pool allocators [Boost], but applications which do this are very few and far between.
Not really, for what a browser tab does, forking a subprocess is pretty cheap. I think the complexity reduction of using a subprocess rather than custom allocators is completely worth the small overhead. And it allows you to continue using system malloc / free, which should be more resilient against exploitation (long live OpenBSD!).
At least as far as my understanding of its VM is concerned, Erlang does something similar to punt on the GC problem–it’s processes all have little heaps that are just zorched when the process dies, and thus it kinda avoids that fragmentation. I have heard, though, that there can be problems with large binaries that are allocated outside the process heap, but for the life of me I don’t know the details right know.
The one I remember is that atoms—fixed strings—are allocated globally and passed by reference. These don’t get properly collected so you at one point could tank a whole Erlang VM by creating loads of them in a loop.
Good post, I agree with almost all of it.
Not really, for what a browser tab does, forking a subprocess is pretty cheap. I think the complexity reduction of using a subprocess rather than custom allocators is completely worth the small overhead. And it allows you to continue using system malloc / free, which should be more resilient against exploitation (long live OpenBSD!).
At least as far as my understanding of its VM is concerned, Erlang does something similar to punt on the GC problem–it’s processes all have little heaps that are just zorched when the process dies, and thus it kinda avoids that fragmentation. I have heard, though, that there can be problems with large binaries that are allocated outside the process heap, but for the life of me I don’t know the details right know.
The one I remember is that atoms—fixed strings—are allocated globally and passed by reference. These don’t get properly collected so you at one point could tank a whole Erlang VM by creating loads of them in a loop.