стейт ген-сервера по ошибке держал буфер ссылающийся (неявно - через окружение захваченное анонимной функцией State#st{buf = [fun() -> do_smth(State#st.field) end | Buf0]}) на предыдущую версию стейта ссылающуются на предыдущую версию стейта ссылающуюся....

вот этот fun() -> ... St#st.field ... end захватывает весь State а не только одно поле из него. Пока оно лежит в heap одного процесса то эти ссылки не сильно вредят. Но если этот стейт попытаться отправить другому процессу (sys:get_state() или крешлог), то всё это дерево начнёт разворачиваться

вот это конечно дичь дикая

и корень проблемы был в том, что вот этот процесс разворачивания и копирования терма для отправки другому процессу (конкретно в статье - до собственно копирования дело даже не дошло - оно всё ешё пыталось посчитать сколько нужно аллоцировать памяти под это) не вытесняется - т.е. занимает целиком один шедулер

но я кажется представил, что должно происходить в компиляторе , чтобы получалось именно так.

в общем, лучше прочитать если интересно

ну это не в компиляторе а в VM.. в сишном коде

или речь о захвате State вместо одного из полей State?

об этом, да

Всем привет!
Кто-нибудь Hamler пробовал щупать?
Как впечатление, какие плюсы и минусы?

For example the 4 byte hexadecimal value 0xdeadbeef becomes <<222,173,190,239>>. Even without the <<>> wrapping, each byte is represented on average on 2.57 digits, or 3.57 characters if we count the comma too. But if the data is stored as a string in Erlang, it will be encoded as a list of Unicode code points, requiring 2 words of storage per list element. So our initial 1 GB binary data pretty printed as a string will take about 1 GB × 3.57 characters/byte × 2 words/character × 8 bytes/word = 57.12 GB memory.

Не оч понял тут про переход от печати binary к string. Имеется ввиду, что результат преобразуют в строку в любом случае, а тогда … x 2 words/character x 8 bytes/word?

ну типа <<222,173,190,239>> это 4 байта а "<<222,173,190,239>>" это по 2 машинных слова на каждую букву в этой строке length("<<222,173,190,239>>") * erlang:system_info(wordsize) * 2. Не уверен что это правильный способ подсчёта...

erlang:system_info(wordsize) видимо в битах

выглядит очень интересно и на гитхабе часто коммиты появляются

но в целом думаю речь о том, что если какой-то терм засунуть в io_lib:format("~p", [Term]), то результат (iolist - строка) будет, как правило, занимать в памяти в разы больше чем исходный терм на heap эрланг-процесса.

чем он интереснее эликсира?

не помню уже

память как у рыбки

походу free variables (то что будет захвачено в окружение fun-а) вычисляется здесь https://github.com/erlang/otp/blob/5c331cb128ffb0cd2c50b33ef298e5eb601b4e8e/lib/compiler/src/v3_kernel.erl#L1975-L1990