которой всенепременно нужно избавляться? Компиляторы нынче умеют проводить escape-анализ и вычислять, что можно размещать на стеке, что можно удалять из кучи при выходе из процедур, есть всякие SoA и AoS структуры данных (если нужен realtime).
Не лучше ли прокачать компилятор, чтобы снизить давление на GC, чем давить дополнительной сложностью на пользователя языка?
Понятно, конечно, что есть AVR, где проблемы с памятью, но есть и такие вот исследования, например:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.2493
В ембеде крайне нежелательно чтобы в неожиданный момент включился сборщик мусора
Да, но компилятор может расставлять safe-points или доказывать, что сборка не нужна. А когда нужна, это можно делать с предсказуемыми задержками.
Понятно, что это усложняет компилятор, и что это не будет точным анализом, а каким-то консервативным приближением. Но действительно ли можно утверждать, что это технически хуже, чем ручное управление a la Rust, например?
В OS A2 с Active Oberon сборщик мусора не останавливает мир ( и не занимается тому подобным). Желательно иметь больше одного ядра CPU. Переходим к практике: если это все не так, то тесты должны выявить.
время вызова сборки и ее необходимость выясняет не компилятор, а заполненная куча
Катати, да. У Вирта же в оригинальном Oberon тоже не было обработчиков прерываний. Компилятор должен был напихивать в код опрос контроллеров, и уходить на обработку событий, если те возникали.
A2 - уже ученики. Прерывания - скорее всего, есть
Обсуждают сегодня