Интервью с ответами на вопросы (
https://docs.google.com/spreadsheets/d/1bieE_mFwAflhsxXCjasLqKJIq3ilUEUWcwI4CE9hEqU/) по Golang с разработчиками
Iron.io, применяющими Go в продакшене - Романом Кононовым (
@rkononov) и Эваном Шоу (Evan Shaw), автором книг по Go и одним из контрибьюторов языка.
Мне понравился ответ Эвана по funarg и call tail optimization. 👍
В разной литературе эта проблема именуется по разному.
Никлаус Вирт писал именно про проблему funarg при реализации компиляторов Modula-2, Oberon/Oberon-2 и Zonnon, при этом различал проблему восходящего и нисходящего фунарга, при движении вверх и вниз по структуре данных дерева (cactus stack или heap), хранящей в узлах стек вызова, контекст вызова сопрограмм.
Тут вся суть в том, какие структуры данных применяются для хранения контекста стека вызова (call stack) go-сопрограмм (goroutines) в runtime компилятора - связываются ли они в cactus stack или используется куча (heap) и как GC производит уборку (особенно если это cactus stack) более не используемого контекста вызова.
Проблема funarg это больше проблема сложности реализации runtime, автоматического управления памятью в GC, выбора быстрой и оптимальной структуры данных (stack or stackless heap) для размещения в ней контекста вызова функций (подпрограмм, subroutines) при исполнении кода.
Насколько я смог разобраться, в Go в зависимости от ситуации применяется тактика размещения как в стеке так и в куче (smarter compiler - именно об этом говорит Эван в ответе), для ускорения и оптимизации исполнения кода, особенно после реализации нового GC с новыми алгоритмами сборки мусора на самом языке Go в версиях 1.5 и 1.6, и завершения полного bootstraping'a компилятора Golang на самом языке Go.
Пожалуй думаю я сделаю ещё пару постов для освещения этой малоизвестной в широких кругах, но весьма важной проблемы.
#Go #Golang