воскресенье, 14 марта 2010 г.

GenCGC

Особенности работы сборщика мусора gencgc в SBCL убили весь смысл больших страниц:
С ростом размера страницы gc начинает тормозить в логарифмической прогрессии. Особо пока не разбирался, но, похоже, это из-за того, что gencgc использует read-write атрибуты страницы в качестве признака необходимости её сканирования. Т.к. теперь на одну страницу приходится 512 бывших маленьких, то одним попаданием в любую часть получаем 511 страниц, которые, возможно, и не надо бы сканировать.

Подход с атрибутами доступа страниц какой-то некошерный, ибо сегфолты, которые сейчас обычное дело, стоят тактов. Плюс решение плохо масштабируется на более крупные страницы.

Как не хочется ковыряться в 170кб сишных исходников... А надо...

P.s.: Надоело рисовать графики в gnuplot, решил потихоньку осваивать R :)

9 комментариев:

  1. А к R есть биндинги для лиспа?

    ОтветитьУдалить
  2. cliki говорит, что есть: http://common-lisp.net/project/rcl/

    ОтветитьУдалить
  3. > Подход с атрибутами доступа страниц какой-то некошерный, ибо сегфолты, которые сейчас обычное дело, стоят тактов. Плюс решение плохо масштабируется на более крупные страницы.

    Зато последующие обращения к странице, уже отмеченной как "грязная", ничего не стоят. Если же реализовывать подобную логику в юзерспейсе, то на каждую запись придётся добавлять дополнительный код, отмечающий страницу как "грязную" (насколько я понял, такой подход реализован в сборщике мусора в java). А без этого придётся забыть про "поколенчатый" сборщик мусора...

    ОтветитьУдалить
  4. > Зато последующие обращения к странице, уже отмеченной как "грязная", ничего не стоят.

    К сожалению, обработка protection fault очень дорого стоит. А ещё ведь ядру придётся ворошить длиннющий vma chain, чтобы найти нужную страницу и сменить ей атрибут. А ещё tlb (translation lookaside buffer) не бесконечной длины.

    Я уж не говорю, что по одному mprotect на каждую страницу а начале цикла gc - это крепчайший маразм. А ещё там делается munmap и следом mmap на тот же адрес. Зачем? Всего этого можно не делать, даже не меняя логики работы gc. У меня крепчает уверенность, что gencgc для sbcl (или cmucl?) писал человек, не очень хорошо разбирающийся в низком уровне.

    > А без этого придётся забыть про "поколенчатый" сборщик мусора...

    Поколения и защита страниц между собой никак не связаны.

    Перерабатывать работу с памятью в SBCL нужно однозначно. Оно уже сейчас плохо выглядит, а что будет в ближайшие годы, когда 8-16 гб будет совсем десктопной попсой? Ну и вопрос с многоядерностью тоже требует внимания, т.к. остановка всех тредов для сборки мусора - это форменное безобразие.

    ОтветитьУдалить
  5. 1. gencgc написан в основном в конце прошлого века, под рефрен "вау, какие в линуксе дешёвые сегфолты!". с тех пор, видимо, "концепция изменилась". :)

    2. задача сборки мусора без "остановки мира", мягко говоря, нетривиальна.

    3. насчёт отсутствия связи между поколениями и защитой страниц (т.е. собственно механизмом реализации "барьера записи") у меня тоже есть большие сомнения.

    ОтветитьУдалить
  6. 1. Ну да, и сисколлы сейчас тоже дешёвые ;)

    2. Как на счёт VCGC? Там, конечно, тред останавливать пару раз надо, но на чуть-чуть. Gencgc, как он есть, на smp очень плохо себя ведёт.

    3. Это, фактически, вспомогательный механизм для раскрашивания. Сборка мусора с поколениями сама по себе (алгоритм) на атрибуты доступа не завязана.

    ОтветитьУдалить
  7. 2. про VCGC не знал, надо почитать, спасибо. жабный сборщик тоже параллельный, и про него я тоже мало знаю (кроме "ужас как сложно"). надо будет ещё поглядеть что гуглеры в результате для Go реализуют...

    3. сборка мусора с поколениями завязана на барьер записи, так или иначе. или пользоваться тем что даёт операционная система (привет mprotect'у), или делать все записи дороже -- и не факт что в результате получится выигрыш. или я совсем отстал от жизни?

    ОтветитьУдалить
  8. Я на сколько понял, G1 - это вариация на тему VCGC.

    Барьер записи в виде mprotect на всю страницу имеет ранее озвученные недостатки: ради, возможно, одного изменённого объекта метятся "грязными" все объекты в странице. Дилемма, в общем.

    Надо выпускать системы, в которых для каждого слова в памяти присутствует набор тэгов :)

    ОтветитьУдалить
  9. http://lib.rus.ec/b/156264

    книга по графике в R.

    Кстати автор первопроходец озаботился тем "почему мы ломанулись писать всё своё, а не взяли cl". Сложности в том, что денег статистикам на развитие собственно R не дают.

    http://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks второй источник на странице.

    ОтветитьУдалить

Архив блога