В этом случае всё ясно и довольно прозрачно. 

Имел ввиду что можно отключить расширение Concurent GC, не более:


В общем я уже сам запутался   

ясно. А я и забыл про gcConcurrent  

Но это ведь дело не меняет - из какого потока не запустился бы GC, он-то все равно все потоки блокирует. Другое дело, что все мучаются, думают как теперь поднимать производительность. 
Вот такая инфа: 
- для участков с неуправляемым кодом применяется технологию "взлом" Hijacking. Смысл в том, что если поток находится в неуправляемом коде, CLR в его стеке встраивает загрушку, которая перехватывает управление на себя, когда поток вернется в управляемый код. Когда она получает управление, она работу потока останавливает и дает GC убрать мусор.
- для участков с управляемым кодом применяется технология Safe Points (безопасные точки). Компилятор для всех функций встраивает в код эти точки. Они говорят о отм, что если код до них дошел, то можно спокойно удалять мусор. Если код выполняется и GC собирается чистить кучу, то он не рубит все потоки безжалостно, а дает возможность каждому потоку дойти до ближайшей safe point и там только поток останавливает.

Вот еще накопал
http://rsdn.ru/article/dotnet/GCnet.xml

Рихтер в картинках   
ну и, как обычно, немного переведенного MSDN.

там и тесты на производительность приведены.

Не совсем понимаю...

С http://rsdn.ru/article/dotnet/GC.xml:

  

Это сообщение отредактировал(а) archeg - 17.5.2007, 21:19

Теперь я не понял 

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

Я так понимаю: 
как выше говорилось, GC работает в своем потоке. По умолчанию. Т.е. как раз когда

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

Не знаю, трудно сказать. Авторов много, и говорят они друг на друга непохоже. Такое ощущение по этой статье, что или чего-то он не договаривает. Все о поколенях, да о поколениях...
Хотел об оптимизации сказать, да что-то мало инфы реальной. Ни про Safe Points, ни про хакинг не сказал. А ведь это есть! Можно в гугле набрать, посмотреть...

Я Рихтеру верю больше  , по крайней мере, он же учил группу мелкомягких (или по компилятору, или по самой CLR, не помню). Во всяком случае, он у них консультант, это я знаю точно.
А вот уважаемый автор http://rsdn.ru/article/dotnet/GC.xml - точно нет   

P.S. Кстати, вот подтверждение и от Рихтера, по крайней мере в книжке его я про Safe Points и хакинг инфы не увидел, из другого источника знаю,  а в гугле - нашел!
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/
"Performance for Multithreaded Applications"

P.S.S. И еще, специально для твоего успокоения  archeg Я без ссылок на авторитеты постараюсь, а то и так ссылок накидали столько, голова кругом идет. Давай с точки зрения здравого смысла определим, чья инфа ближе к истине?

Отдельный поток GC: и для мониторинга памяти, в том числе, нужен. Должна же CLR понять, когда памяти начинает нехватать и нужно GC вызывать, правда? 
Да, GC строит графы в своем потоке. А где он должен их строить? В код программы директивы что-ли встроить, чтобы через каждые три такта прыгать на построение графов, а вдруг памяти мало, много сборок в домен загрузили?

А системмных потоков, на самом деле, еще больше. Есть еще один зарезервированный поток для финализатора. Те корни, что поддерживают финализаторы в этом, отдельном от простых корней, потоке завершаются. Да и другие... Например, для многопроцессорной системы на каждый процессор - отдельный GC со своим потоком. Как говориться, потоков у нас для всех хватит. 

Так что не зацикливайся на потоках. Вот статья http://blogs.msdn.com/yunjin/archive/2005/07/05/435726.aspx (я упоминал уже ее) точно описывает сколько и какие потоки существует в CLR:

Finalizer thread
Debugger helper thread
Concurrent GC thread
Server GC threads
App Domain unload helper thread
Threadpool threads
( и, добавлю от себя, еще столько Thread-ов, сколько ты сможешь создать с помощью new Thread(ThreadStart)  ) 
не получилось без авторитетов 

Суть в другом: потоки выполнения блокируются. Еще ни один чел не сказал, что сборка мусора не тормозит приложение. А как приложение может тормозить? Только приостановкой потоков выполнения.

Это сообщение отредактировал(а) tol05 - 17.5.2007, 23:45

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



Concurrent GC действует только во втором поколении - в первом и нулевом он не имеет смысла.

Рихтера стоит почитать, жалею что нету его под рукой :(

Это сообщение отредактировал(а) archeg - 17.5.2007, 23:36