[x-yuri]

И то и то слвится своим "быстродействием".)

Про java слышал, что до сих пор славится по инерции, типа оснований для этого уже нету. Про .net вообще не слышал такого.

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

Concurent GC – это второй вид оптимизации процесса сборки мусора. Его суть заключается в том, что процесс построения графа объектов ведется без приостановки управляемых потоков. Вместо этого запускается специальный GC-поток, строящий граф. Поскольку в любой момент управляемые потоки могут изменить граф и вообще пересечься с GC-потоком, требуется синхронизация со всеми операциями, модифицирующими управляемые ссылки. Естественно, что параллельный GC-поток и необходимость синхронизации (подробнее см. раздел «Барьер записи») не могут не замедлить процесс сборки мусора по сравнению с обычной схемой. Однако во многих случаях такое замедление незаметно. Зато это позволяет избавиться от паузы, вызванной построением графа объектов. Малый размер пауз выгоден для интерактивных приложений. Особенно в нем нуждаются GUI-приложения и игры. Не мудрено, что именно этот режим используется в .NET Framework по умолчанию.

http://www.rsdn.ru/article/dotnet/GC.xml#ENE

Там же написано про поколения, т.е. нету необходимости обходить все переменные.

Контрольный: почему они выбрали mark and sweep если подсчет ссылок такой весь из себя положительный?

Чем больше смотрю на работу браузеров, тем больше мне кажется, что почти все они сделаны через жопу.

Я думаю, надо написать свой браузер, чтобы понять разработчиков браузеров