В чем преимущество выполнения GC во время компиляции ARC?

Некоторые новые языки внедряют ARC в свои компиляторы (Swift и Rust, чтобы назвать пару). Насколько я понимаю, это обеспечивает то же самое, что и GC (время выполнения ручного освобождения от программиста), но при этом значительно более эффективно.

Я понимаю, что ARC может стать сложным процессом, но со сложностью современных сборщиков мусора, похоже, было бы сложнее реализовать ARC. Тем не менее, все еще есть много языков и фреймворков, использующих GC для управления памятью, и даже язык Go, который ориентирован на системное программирование, использует GC.

Я действительно не понимаю, почему GC предпочтительнее ARC. Я что-то пропустил?

1 ответ

Здесь есть куча компромиссов, это сложная тема. Здесь большие, но:

Преимущества GC:

  • Трассировка сборщиков мусора может обрабатывать циклы в графах объектов. Автоматический подсчет ссылок будет утечка памяти, если цикл не будет ручным, либо удалив ссылку, либо выяснив, какой край графика должен быть слабым. Это довольно распространенная проблема на практике в подсчитанных приложениях.
  • Трассировка сборщиков мусора на самом деле может быть умеренно быстрее (с точки зрения пропускной способности), чем подсчет ссылок, выполняя работу одновременно, путем доработки, откладывая работу и не испорчая кэши, касаясь ссылок на ссылки в горячих циклах.
  • Копировальные коллекторы могут уплотнять кучу, восстанавливая фрагментированные страницы, чтобы уменьшить площадь.

Прогресс ARC:

  • Поскольку уничтожение объектов происходит немедленно, когда счетчик ссылок достигает 0, время жизни объекта может использоваться для управления ресурсами без памяти. С сборкой мусора продолжительность жизни недетерминирована, поэтому это не безопасно.
  • Коллективная работа, как правило, более распространена, что приводит к гораздо более коротким паузам (все еще возможно получить паузу, если вы освободите большой подграф объектов)
  • Поскольку память собирается синхронно, невозможно "обогнать коллектор", выделяя быстрее, чем она может очистить. Это особенно важно, когда пейджинг VM вступает в игру, поскольку существуют дегенеративные случаи, когда поток GC попадает на страницу, выгруженную и отстает.
  • В соответствующей заметке трассировка сборщиков мусора должна пройти весь графический объект, что заставляет ненужные страницы (для этого есть смягчение, например https://people.cs.umass.edu/~emery/pubs/f034-hertz.pdf, но они не широко развернуты).
  • Трассировка сборщиков мусора обычно требует большего количества "царапин", чем подсчет ссылок, если они хотят поразить свою полную пропускную способность.

Мой личный подход заключается в том, что в большинстве случаев для большинства случаев важны только две точки:

  • ARC не собирает циклы
  • GC не имеет детерминированных времен жизни

Я чувствую, что обе эти проблемы - разрывы сделок, но при отсутствии лучшей идеи вам просто нужно выбрать, какая ужасающая проблема звучит хуже для вас.

licensed under cc by-sa 3.0 with attribution.