Если вы разрабатывали язык программирования, который поддерживает автоматическое управление памятью, использовал бы подсчет ссылок, чтобы гарантировать гарантии детерминизма, которые невозможны с сборщиком мусора?
Будет ли другой ответ на этот вопрос для функциональных и императивных языков?
Будет ли использование подсчета ссылок допускать гарантии детерминизма, которые невозможны с сборщиком мусора?
Слово "гарантия" является сильным. Вот гарантии, которые вы можете предоставить с помощью подсчета ссылок:
Накладные расходы на постоянное время при назначении для корректировки отсчетов ссылок.
Постоянное время для освобождения объекта, счетчик ссылок которого равен нулю. (Ключ в том, что вы не должны сразу уменьшать этот объект, вместо этого вы должны делать это лениво, когда объект используется для удовлетворения будущего запроса на выделение.)
Постоянное время для размещения нового объекта, когда соответствующий свободный список не пуст. Эта гарантия условна и не стоит многого.
Вот некоторые вещи, которые вы не можете гарантировать при подсчете ссылок:
Постоянное время для размещения нового объекта. (В худшем случае куча может расти, и в зависимости от системы задержка для организации новой памяти может быть значительной. Или, что еще хуже, вы можете заполнить кучу и не можете выделить.)
Все недостижимые объекты возвращаются и повторно используются, сохраняя постоянное время для других операций. (Стандартный ссылочный счетчик не может собирать циклический мусор. Существует множество изобретательных обходных решений, но обычно они недействительны для постоянных гарантий для простых операций.)
В настоящее время есть сборщики мусора в реальном времени, которые предоставляют довольно интересные гарантии времени паузы, и за последние 5 лет были интересные разработки как для подсчета ссылок, так и для сбора мусора. С того места, где я сижу как информированный аутсайдер, нет очевидного победителя.
Некоторые из лучших последних работ по подсчету ссылок - Дэвид Бэкон из IBM и Эрез Петранк из Technion. Если вы хотите узнать, что может сделать сложная современная система подсчета ссылок, посмотрите их документы. Среди прочего, они используют несколько процессоров удивительными способами.
Информацию об управлении памятью и гарантиях в реальном времени в более общем плане можно найти в Международном симпозиуме по управлению памятью.
Будет ли другой ответ на этот вопрос для функциональных и императивных языков?
Потому что вы спрашивали о гарантиях, нет. Но для управления памятью в целом компромиссы производительности весьма различны для императивного языка (много мутаций, но низкие уровни распределения), нечистый функциональный язык (вряд ли какая-либо мутация, но высокая скорость распределения) и чистый, ленивый функциональный язык (партии мутации, все те, кто думает, обновляется и высокие ставки распределения).
будет использовать подсчет ссылок, чтобы гарантировать гарантии детерминизма, которые невозможны с сборщиком мусора?
Я не понимаю, как это сделать. Процесс снижения ссылочного счета объекта не ограничен по времени, так как этот объект может быть единственным корнем для произвольного большого объекта.
Единственный способ подойти к проблеме GC для систем реального времени - это использовать либо параллельный коллектор, либо инкрементный - и независимо от того, использует ли система подсчет ссылок или нет; на мой взгляд, ваше различие между подсчетом ссылок и "сбором" в любом случае не является точным. системы, которые используют подсчет ссылок, могут иногда выполнять некоторую разметку памяти (например, для обработки циклов).
Вам может быть интересно IBM Metronome, и я также знаю, что Microsoft провела некоторые исследования в направлении хорошего управления памятью в реальном времени.
Если вы посмотрите на спецификацию RTSJ (JSR-1), вы увидите, что они столкнулись с проблемой, предоставив потоки реального времени без кучи. Имея отдельную категорию нити, которой не разрешено касаться каких-либо объектов, которые могут потребовать остановки потока для сбора мусора, сторона JSR-1 сделала это. Сейчас не так много реализаций RTSJ, но область сбора мусора в реальном времени является горячей темой в этом сообществе.
В режиме реального времени сбор мусора может быть вредным, потому что вы не знаете, когда сборщик мусора соберется... так что да, подсчет ссылок в этом контексте определенно лучше.
В качестве побочного примечания, как правило, в системе реального времени только некоторые части нуждаются в обработке в реальном времени, поэтому вы можете избежать сбора мусора только в чувствительных компонентах. Пример реального мира - это программа на С#, работающая на цели Windows CE.
Для программирования в реальном времени учет ссылок имеет преимущество перед сборкой мусора с точки зрения детерминизма?
Да. Основным преимуществом подсчета ссылок является простота.
Если вы разрабатывали язык программирования, который поддерживает автоматическое управление памятью, использовал бы подсчет ссылок, чтобы гарантировать гарантии детерминизма, которые невозможны с сборщиком мусора?
GC, подобный Bread Treadmill, должен получить тот же уровень гарантий относительно детерминизма, который предлагает подсчет ссылок.
Будет ли другой ответ на этот вопрос для функциональных и императивных языков?
Да. Только подсчет ссылок не обрабатывает циклы. Некоторые функциональные языки делают невозможным создание циклов по дизайну (например, Erlang и Mathematica), поэтому они тривиально допускают подсчет ссылок только как точный подход к GC.
Из-за некоторой вовлеченности в различные проекты, переносящие значимые куски кода из С++ (с различными классами интеллектуальных указателей, включая подсчет ссылок) на мусор, собранный Java/С#, я заметил, что самые большие точки боли, похоже, связаны с классами непустые деструкторы (особенно при использовании для RAII). Это довольно большой флаг, который предполагает детерминированную очистку.
Проблема, безусловно, одинакова для любого языка с объектами; Я не думаю, что гибридные OO-функциональные языки, такие как Scala или Ocaml, обладают определенными преимуществами в этой области. Ситуация может отличаться для более "чистых" функциональных языков.