[erlang-questions] how to break the problem. the erlang way?

[Ovidiu Deac]

Nice.

So basically allocating the memory for a new process should be very
fast (like stack allocation?) and then growing/cleaning it's heap
will be performed only when the process runs out of heap space. Since
every process has it's own non-shared data then it will have a
per-process gc which is guaranteed that it won't run as long as the
process' heap needs fit in the min_heap_size provided by spawn_opt.

So if I determined a min_heap_size (after proper measurement of
course) can I rely on the fact gc won't run on any platform? Or maybe
this size depends on the erlang vm implementation? I'm thinking about
32 vs 64 bit platforms. If this is the case I should use the maximum
detected for the intended deployment platforms.

For this tuning phase how can I detect that gc was called for a process?

On Fri, Jul 31, 2009 at 11:39 PM, Mihai Balea<mihai@REDACTED> wrote:
>
> On Jul 31, 2009, at 4:27 PM, Witold Baryluk wrote:
>
>> Dnia 2009-07-31, pią o godzinie 23:09 +0300, Ovidiu Deac pisze:
>>>
>>> On Fri, Jul 31, 2009 at 6:41 PM, Mihai Balea<mihai@REDACTED> wrote:
>>
>> h
>>>>
>>>> One advantage of having transient processes is that you can tune them to
>>>> never need garbage collection, which is not the case for long lived
>>>> processes.
>>>
>>> Can you detail this part? I don't think I understand what you mean by
>>> "tune them to never need garbage collection" but it sounds good :)
>>
>> I think He mean that if spawned process will do its job quickly
>> (and it will not trigger garbage collection due to small usage of own
>> heap and stack), all memory will be freed after its terminate.
>> So it will still reclaim its memory, but it will be trivial and
>> ultra fast.
>
> Yes, that is gist of it.
>
> GC in Erlang is done on a per-process basis - each process has its own heap
> that is managed  and collected independently.
> If the process is sufficiently short lived, it will terminate before GC is
> triggered and the entire process memory is reclaimed in one very fast  step.
> By "fine-tuning" I was referring to the ability to set the initial process
> heap, when you spawn the process.
>
> Mihai