• garbage_collection Существует в общепринятых практиках ряд решений, которые меня в корне не устраивают. Одно из таких решений — использование сборщиков мусора, которые добавляют недетерминированные задержки в программу. В качестве альтернативы активно используется два подхода: Не собирать мусор и использовать сборщик мусора подсчитывающий количество ссылок. Проблемы этих подходов неоднократно описаны и сами подходы много раз раскритикованы.
    Очевидным выходом из положения была бы разработка сборщиков мусора времени компиляции лишенных недостатков метода подсчёта ссылок (проблема: они очевидным образом не могут быть применены в большинстве языков), но работ в эту тему удивительно мало. Из того что можно посмотреть за вечер только mercury.cs.mu.oz.au

Replies (4)

  • @Kim, Еще нашлось что-нибудь?
  • @balodja, cs.tau.ac.il — только просматривал. На сколько я понял — работа с функциональным кодом, анализ в каких местах можно повторно использовать ячейки данных, но полностью от сборки мусора не избавляет.
    scss.tcd.ie — подсчёт ссылок во время компиляции. Ссылки подсчитываются так, чтобы число ссылок в конкретном месте в коде было ≥ реальному числу ссылок во время выполнения.
    dspace.mit.edu — аргументация за то, что выделение памяти на стеке, в ряде случаев, эффективнее чем копирующие сборщики мусора — ответ на cs.princeton.edu . Забавно, но если вы будете искать по ключевым словам "garbage collection on a stack", то скорее всего найдёте про вариант копирующих сборщиков мусора, а не про возможность компиляции чего-либо на Forth-подобный язык с размещением всех данных на стеке.

    scholarship.rice.edu — Текст про то, что сборщики мусора времени выполнения делают невозможными ряд оптимизаций кода.

    Кроме этого есть ряд работ про сборщики мусора реального времени — то есть про сборщики мусора, которые не требуют остановки программы для своей работы. Часть статей просматривал, но там было про дизайн железа, который бы оптимизировал сборку мусора. В чисто софтверном виде, на сколько я понимаю, это требует корректного двухпоточного менеджера кучи.

    Собственно это всё что я нашел. Такое впечатление, что кроме как в Mercury, сборщики мусора времени компиляции не используются (или используются очень слабо для работы с локальными переменными, значения которых не будут передаваться между функциями).
  • @Kim, Всё таки сел за чтение статей и в них во всех под сборкой мусора времени компиляции имеется ввиду вставка инструкций добавления элемента в free list для Mark and Sweep сборщиков мусора, либо деструктивное присваивание в языках с копирующими сборщиками мусора. На самом деле надо читать про "Static memory (de)allocation".
  • @Kim, прочитал ещё несколько статей и получил такую картину: В 60е годы создавались языки, которые всю память выделяли статически. После этого развитие пошло по пути динамического ручного управления кучей. Это, на сколько я понял было около конца семидесятых. Следом в языки добавили сборку мусора на подсчете ссылок и после этого современные сборщики мусора. Где то параллельно (середина восьмидесятых, начало девяностых) начали использовать явное и неявное region based выделение памяти, разработали методы анализа потока данных, улучшали методы определения что можно выделять на стеке... Но языков в которых память очищается статически больше не писали. Параллельно, конечно, есть история Форта и его наследников. Но в форте понятно что динамическая куча не нужна. А стек данных (не путать со стеком адресов) как единственная динамическая память гарантирует своевременную очистку памяти.

    Так что, судя по всему, имеет смысл попробовать собрать все наработанные за три десятилетия методы анализа потоков кода и данных (по отчетам они могут найти для 0-98% объектов места в которых эти объекты больше не будут использоваться) и методы статического управления памятью (размещение на стеке, размещение в регионах) и посмотреть на сколько выразительным может быть язык без динамического управления памятью.