Кто-нибудь может объяснить как работает этот метод сборщика мусора. В приведенном ниже коде, если удалить строчку с методом GC.KeepAlive(mt); программа начинает работать так, словно мутекс не создавался.



Что  делает метод GC.KeepAlive() я могу понять по документации, меня интересует как метод, который вызывается после завершения программы может препятсявовать удалению объекта сборщиком мусора? Сложилось впечатление что это деректива препроцессору...

Это сообщение отредактировал(а) v00d00 - 2.2.2009, 13:13

Он не подбирается сборщиком, потому что на него ссылка имеется при вызове метода GC.KeepAlive(mt). Вот поэтому он и живет до конца приложения, т.е. пока не закроется главная форма в твоем случае.
А метод этот делает ссылку на указанный объект, делая его недоступным для сборщика мусора с момента начала текущей процедуры до вызова этого метода. Чтобы лучше понять это, нужно понять принципы работы GC.

Если бы я вместо этого метода обратился к свойству объекта, эффект был бы такой же? На этапе компиляции сгенерировался бы код, запрещаюший удаление этого объекта? Ведь по идее до завершения программы переменная-указатель будет продолжать лежать на стеке?



Он делает ссылку на объект после того как он теоретически может быть уничтожен?

Если бы ты использовал объект после закрытия гл. формы, то все время работы приложения он бы не уничтожился, так как на него будет ссылка. Объекты хранятся в куче, кроме структур value type - они хранятся в стеке и уничтожаются при выходи из области видимости автоматически. GC ходит по куче, считает ссылки и ликвидирует объекты. Уничтожение проходит в несколько этапов, это прочитать нужно.
Да, только если и после этого на него не будет ссылок. Если нужно чтобы объект жил, то лучше написать GC.KeepAlive(mt); чем Mutex tmp = mt;

Mutex mt = new Mutex(true, "BudPDMLibAdmin", out MutexWasCreated); Это строка находится выше на уровень вложенности, чем получивший управление код, следовательно переменная mt гарантированно будет лежать на стеке до завершения программы. 

Или сборщик видит что потом она нигде не используется и удаляет объект по ней?

Если переформулировать мои вопрос, то он будет выглядеть так: Почему сборщик удаляет объект под переменной, которая все еще лежит на стеке, но не используется? Ссылка то еще живая, и умрет только по выходу управления из функции.

 Переменная всего лишь хранит в себе ссылку, а сам объект лежит не в стеке, а в куче. После создания мутекса при отсутствии GC.KeepAlive(mt); на созданный объект больше не ссылается не одна переменная и поэтому сборщик уничтожает объект за ненадобностью.
 Да, так он поступает с сылочными типами.

Это бы работал, если бы мутекс был структурой и хранился в стеке, тогда бы сборщик его не достал. Но он хранится в куче и поэтому сборщик его уничтожит, если на него не будет ссылок.

Почитай про ссылочные типы и типы значений и про сборщик, сразу станет понятнее.

v00d00, mt не будет лежать на стеке. Объект будет создан в куче




Ага...сборщик умный...

В debug JIT продлевает время жизни переменной до ее scope - чтобы в отладке можно было посмотреть значение после последнего использования. В release время жизни значительно сокращается 

На сколько я знаю, то JIT это способ компиляции и JIT  компиляторы. А за временем жизни объектов следит CLR - сборщик мусора. Как с этим справляется IDE мне доподленно не известно, возможно для переменных хранит ссылки на них во время отладки для показана сведений по ним.

Насколько я знаю, сборщик мусора за временем жизни объектов не следит. Он тупо пробегается по дереву объектов начиная с корней "корням" и все, что не увидит, подметает. Перменные в стеке (ссылки), глобальные переменные, значения в регистрах - это корни. Лежит ли переменная в стеке в конкретный момент, или давно выброшена и не используется - определяется JIT. И именно JIT дает GC список смертников - GC Info. Вот краткая инструкция по наблюдению за процессом в дикой природе:
http://blogs.msdn.com/yunjin/archive/2005/05/15/417569.aspx

Это сообщение отредактировал(а) PashaPash - 5.2.2009, 10:39

В подтверждение слов PashaPash - можно посмотреть еще у Рихтера - глава 20, часть называется "Сбор мусора и отладка". Там подробно расписываются особенности работы JIT-компилятора с /debug и /optimize сборками

Вот как раз сборщик и следит. Jit при генерации кода кроме прочего создает корни и никаких смертников не дает сборщику. Это сборщик сам определяет есть ли ссылки на объект или нет. Jit не занимается поиском смертников этим занимается как раз таки сборщик, маркирует и т.д.

Про отладку я и писал, что мне доподленно не известно, но как я и предполагал, хранит ссылки, но только не IDE а сам JIT, он генерит внутреннюю таблицу корней.

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

Спасибо за разъяснения, на будущее запомню, когда работаем с неуправляемым кодом, объекты с ресурсами нельзя позволять удлать сборщику.

И на сколько я понял метод KeepAlive на самом деле ничего не делает, просто в коде хранится смещение ссылки на стеке, которая указывает на объект, который лежит в куче...)))) так сказать для красоты

Наверное это вопрос, а не критика. 
(пример из рихтера)
Обычный режим.
JIT-сгенирил все свою лабуду и корни в том числе.
После вызова GC.Collect(); сборщик удалит объект (речь идет о Timer), так как при поиске ссылок он не найдет ничего.
Режим отладки.
JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать, чтобы при вызове GC.Collect(); сборщик увидел что есть ссылки и не удалил объект до конца метода мэин. По простому так.
JIT не занимается поиском смертников, для этого и создан сборщик и он управляет жизнью объекта так сказать.

Это сообщение отредактировал(а) emmanuil - 5.2.2009, 14:19