[erlang-questions] What is "Abandon carrier utilization limit" for?
Fri Oct 13 20:08:49 CEST 2017
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
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.
>>> 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
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
It disables carrier migration as only scheduler threads can use the
lock-free carrier pool implementation.
More information about the erlang-questions