Re[3]: Мысли о эффективном автоматическом управлении памятью
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 28.10.14 19:15
Оценка: +4
Здравствуйте, VladD2, Вы писали:

DM>>чтобы можно было собирать лишь молодое/эфемерное поколение надо отлавливать все возникающие указатели на молодые объекты из старых, для этого нужны барьеры в том или ином виде.


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


Это и есть барьер в одном из видов, об этом я (автор того блога) там упомянул явно. Фишка в том, что это очень недешевая штука.
first write access to a page allocated with VirtualAlloc+MEM_WRITE_WATCH: 1800 cycles
.. page allocated with VirtualAlloc+ResetWriteWatch: 1100 cycles
Ты думаешь, что если переложить на ОС, то все внезапно бесплатно и мгновенно? Наивный какой.

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


Ню-ню. Опытный дядя хоть один GC написал в своей жизни? Или аллокатор хотя бы?


VD>Более простые алгоритмы ведут к фрагментации — значит мы можем нарваться на атофмемори, получаем худшую локальность данных (промахи мимо кэша) и прочими проблемам.


Напомнить тебе типичный размер кэш-линии? Есть ли разница с т.з. кэша, лежат ли два объекта в 200 байтах друг от друга или в 200 килобайтах? (ответ — нет)


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


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


А ты попробуй свою идею сперва додумать до конца. Ты предлагаешь ввести ссылку, которую нельзя заныкать и нельзя "возвращать за пределы области видимости где она создана". Передавать ее в другие функции можно? А возвращать полученную в аргументе? Возьмем такой псевдокод:
ptr f(ptr x) { return x; }

ptr g() {
  ptr p = create_scoped_pointer();
  return f(p);
}

Как именно будешь тут бороться с утеканием ссылки наверх?
Тебе придется или вовсе запретить их возвращать (это решит часть проблем, но принесет много неудобств), или добавлять в язык явное указание лайфтаймов, как в Расте.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.