[erlang-questions] What is "Abandon carrier utilization limit" for?

[Sverker Eriksson]

On 10/13/2017 07:33 PM, Roger Lipscombe wrote:
>> So no, moving block between carrier does not even make sense.
> I guess I meant: can the VM copy the content to another block in a
> "live" carrier, thus freeing up this carrier, but I guess that'd
> involve updating all kinds of pointers, and that stuff happens at a
> higher level in the VM, right?

No, we don't do that. It can get very complicated in the general case as 
the higher level code has to update all pointers to the block in a 
thread-safe manner.

We did some experimental hacks for binary_alloc where it could maybe be 
feasible as the data is read-only.

>>> Or is it that, once a carrier falls below the threshold, the VM tries
>>> not to use it, so that it's more likely (assuming that the remaining
>>> content eventually gets freed) that it'll get returned to the OS?
>> Yes, that is the idea.
> Cool.
>
>>> Also: what is the default setting? The documentation says "de", but
>>> system_info is saying "0" for all of my allocators. Is "de" choosing
>>> zero for me?
>>>
>>>
>> Hmm.... I'll be back...
> OTP 20-rc2, btw; I'll try a newer build... I'll be back... :)
>
system_info(allocator) only gives an overview which can be a bit misleading.
If you look at the individual allocator instances with for example

erlang:system_info({allocator, ets_alloc}).

you will see all instances except #0 have non zero values for 'acul'.

Instance #0 is a lock protected allocator used only by non-scheduler 
threads.
It disables carrier migration as only scheduler threads can use the 
lock-free carrier pool implementation.


/Sverker