Fri Sep 3 16:44:44 CEST 1999
>>>>> On Thu, 2 Sep 1999 23:38:42 -0700 (PDT), Patrick Logan <patrickdlogan@REDACTED> said:
> A problem with a heap per process seems to be how much heap to
> allocate to each process, and handling the processes that outgrow
> their heap.
Another approach would be to do something like Caml Light. Each
process has a small heap. Objects that are smaller than a certain
size are allocated from this heap. When a process does a minor
collection, its live data is moved to the shared heap. This
per-process heap is usually something small, like 32k. (The small
heap is also only for non-mutable objects).
The large heap is the collected in a more coordinated way. This ends
up as a kind of hybrid copying and mark-sweep collector. The first
generation is copying (but only for small objects), and the subsequent
generation is collected normally.
The large heap will need to use a real time collection algorithm,
whereas the small heaps can just be copied through in their entirery.
They can be chosen to be small enough that this collection runs fast
When a message is passed, it is checked to see which heap it is in,
and only if it is in a small heap is it copied. That way, especially
large messages will avoid the copy.
I'm still looking for the article. Hopefully I will find it when I
return from my trip (Monday is a holiday in the US).
More information about the erlang-questions