Здравствуйте, D. Mon, Вы писали:

DM>Даже без инкрементальной или конкурентной сборки нужны write barriers по очень простой причине: если у тебя GC с поколениями, и язык разрешает менять указатели в объектах старших поколений (в отличие от Эрланга, например, где все иммутабельно и такой проблемы нет), то чтобы можно было собирать лишь молодое/эфемерное поколение надо отлавливать все возникающие указатели на молодые объекты из старых, для этого нужны барьеры в том или ином виде. Т.е. этот вот оверхед неизбежен при наличии generational GC. А без поколений GC настолько медленный, что и говорить не о чем.

DM>Подробнее о проблеме, с картинками:
DM>http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

Ты и автор этого блока просто не знаешь, что в 21 веке эту работу можно переложить на ОС, которая отследит изменение памяти с помощью прерываний. В Винде для этого используется флаг MEM_WRITE_WATCH при вызове функции VirtualAlloc() и GetWriteWatch() для того чтобы получить список измененных страниц.

Так что слушайте что вам опытный дядя говорит . Эта проблема решена аппаратно. Барьеры нужны только в конкурентных GC.

DM>А много ты на Расте написал кода, чтобы так говорить? Этот пункт вызывает сомнения.

Не нужно быть курицей, чтобы знать толк в яичнице. Мне достаточно почитать код, чтобы оценить сколько нужно держать в голове, для использования предложенного в Раст механизма.

Кроме того я спрашивал у Киберакса о том насколько это гиморно. Он сказал, что примерно как в С++.

VD>>Причем у этого подхода есть и ограничения. Так указатель в Rust не отслеживается, а значит он не должен сдвигаться. Это значит, что точный GC (GC поддерживающий дефрагментацию) вряд ли может быть использован в Rust.

DM>Мне думается, что проблему фрагментации ты несколько преувеличиваешь. Если аллокатор, как какой-нибудь tcmalloc, имеет разные free-list'ы для объектов разных размеров, то никакой особой фрагментации и не возникает. Впрочем, здесь я могу и ошибаться.

Во-первых, ничего кроме дефрагментации с перенесением объектов не решает проблему фрагментации на 100%.
Во-вторых, за все нужно платить. Продвинутая логика по спасанию и объединению/разбиению свободных блоков замедляет алгоритм выделения и освобождения память. Стало быть мы платим скоростью. Более простые алгоритмы ведут к фрагментации — значит мы можем нарваться на атофмемори, получаем худшую локальность данных (промахи мимо кэша) и прочими проблемам.

DM>И вот мы и получили Rust. Твое предложение, совершенно оправданное и разумное, полностью эквивалентно (с т.з. компилятора и усложнения языка для программиста) той системе контроля лайфтаймов, что есть в Расте.

Не совсем. В Расте, во-первых, отказались от GC, а во-вторых, предлагают возиться с временем жизни явно, что заставляет программиста уделять этому слишком много времени.

А та я и не скрываю, что присматриваюсь к тому что они там творят.