Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > .NET для новичков > GC.Collect

Автор: v00d00 2.2.2009, 12:54

Кто-нибудь может объяснить как работает этот метод сборщика мусора. В приведенном ниже коде, если удалить строчку с методом GC.KeepAlive(mt); программа начинает работать так, словно мутекс не создавался. Код bool MutexWasCreated;             //создаем глобальный Mutex для предотвращения повторного запуска приложения             Mutex mt = new Mutex(true, "BudPDMLibAdmin", out MutexWasCreated);             if (MutexWasCreated)             {                                  Application.EnableVisualStyles();                 Application.SetCompatibleTextRenderingDefault(false);                 // Add the event handler for handling UI thread exceptions to the event.                 Application.ThreadException += new ThreadExceptionEventHandler(AppExceptionHandler.UIThreadException);                 Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);                 Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;                 try                 {                     log4net.Config.XmlConfigurator.Configure();                     if (log.IsInfoEnabled)                         log.Info("===== " + BudPDMLib.Admin.Properties.Resources.cStrLogAppStarted + " " + Application.ExecutablePath + " =====");                     Application.Run(new MainForm());                     if (log.IsInfoEnabled)                         log.Info("===== " + BudPDMLib.Admin.Properties.Resources.cStrLogAppFinished + " " + Application.ExecutablePath + " =====");                 }                 catch (Exception e)                 {                     BaseAppUtils.ShowErrorProduct(e.Message);                 }                 //Не дать сборщику муссора удалить мутекс до завершения приложения                 GC.KeepAlive(mt);             }             else             {                 BaseAppUtils.ShowWarningSimple(Properties.Resources.cStrWarningAlreadyRuning);             } Что  делает метод GC.KeepAlive() я могу понять по документации, меня интересует как метод, который вызывается после завершения программы может препятсявовать удалению объекта сборщиком мусора? Сложилось впечатление что это деректива препроцессору...

Автор: emmanuil 3.2.2009, 10:36

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

Автор: v00d00 4.2.2009, 17:10

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

Автор: emmanuil 4.2.2009, 17:59

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

Автор: v00d00 4.2.2009, 18:26

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

Автор: emmanuil 4.2.2009, 18:46

Цитата(v00d00 @  4.2.2009,  16:26 ) Mutex mt = new Mutex(true, "BudPDMLibAdmin", out MutexWasCreated); Это строка находится выше на уровень вложенности, чем получивший управление код, следовательно переменная mt гарантированно будет лежать на стеке до завершения программы.   Переменная всего лишь хранит в себе ссылку, а сам объект лежит не в стеке, а в куче. После создания мутекса при отсутствии GC.KeepAlive(mt); на созданный объект больше не ссылается не одна переменная и поэтому сборщик уничтожает объект за ненадобностью. Цитата(v00d00 @  4.2.2009,  16:26 ) Или сборщик видит что потом она нигде не используется и удаляет объект по ней?  Да, так он поступает с сылочными типами. Цитата(v00d00 @  4.2.2009,  16:26 ) Если переформулировать мои вопрос, то он будет выглядеть так: Почему сборщик удаляет объект под переменной, которая все еще лежит на стеке, но не используется? Ссылка то еще живая, и умрет только по выходу управления из функции. Это бы работал, если бы мутекс был структурой и хранился в стеке, тогда бы сборщик его не достал. Но он хранится в куче и поэтому сборщик его уничтожит, если на него не будет ссылок. Почитай про ссылочные типы и типы значений и про сборщик, сразу станет понятнее.

Автор: Partizan 4.2.2009, 18:51

Цитата следовательно переменная mt гарантированно будет лежать на стеке v00d00, mt не будет лежать на стеке. Объект будет создан в куче Цитата Или сборщик видит что потом она нигде не используется и удаляет объект по ней? Ага...сборщик умный...

Автор: PashaPash 4.2.2009, 21:14

Цитата(v00d00 @  4.2.2009,  18:26 ) Mutex mt = new Mutex(true, "BudPDMLibAdmin", out MutexWasCreated); Это строка находится выше на уровень вложенности, чем получивший управление код, следовательно переменная mt гарантированно будет лежать на стеке до завершения программы.  Или сборщик видит что потом она нигде не используется и удаляет объект по ней? В debug JIT продлевает время жизни переменной до ее scope - чтобы в отладке можно было посмотреть значение после последнего использования. В release время жизни значительно сокращается

Автор: emmanuil 5.2.2009, 05:44

Цитата(PashaPash @  4.2.2009,  19:14 ) В debug JIT продлевает время жизни переменной до ее scope - чтобы в отладке можно было посмотреть значение после последнего использования. В release время жизни значительно сокращается  На сколько я знаю, то JIT это способ компиляции и JIT  компиляторы. А за временем жизни объектов следит CLR - сборщик мусора. Как с этим справляется IDE мне доподленно не известно, возможно для переменных хранит ссылки на них во время отладки для показана сведений по ним.

Автор: PashaPash 5.2.2009, 10:38

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

Автор: WarHog 5.2.2009, 12:13

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

Автор: emmanuil 5.2.2009, 13:01

Цитата(PashaPash @  5.2.2009,  08:38 ) Насколько я знаю, сборщик мусора за временем жизни объектов не следит. Он тупо пробегается по дереву объектов начиная с корней "корням" и все, что не увидит, подметает. Перменные в стеке (ссылки), глобальные переменные, значения в регистрах - это корни. Лежит ли переменная в стеке в конкретный момент, или давно выброшена и не используется - определяется JIT. И именно JIT дает GC список смертников - GC Info.: Вот как раз сборщик и следит. Jit при генерации кода кроме прочего создает корни и никаких смертников не дает сборщику. Это сборщик сам определяет есть ли ссылки на объект или нет. Jit не занимается поиском смертников этим занимается как раз таки сборщик, маркирует и т.д. Цитата(emmanuil @  5.2.2009,  03:44 )  Как с этим справляется IDE мне доподленно не известно, возможно для переменных хранит ссылки на них во время отладки для показана сведений по ним. Про отладку я и писал, что мне доподленно не известно, но как я и предполагал, хранит ссылки, но только не IDE а сам JIT, он генерит внутреннюю таблицу корней.

Автор: WarHog 5.2.2009, 13:49

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

Автор: v00d00 5.2.2009, 14:12

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

Автор: emmanuil 5.2.2009, 14:17

Цитата(WarHog @  5.2.2009,  11:49 ) emmanuil, как я понимаю, при генерации машинного кода JIT-компилятор в генерируемой им внутренней таблице корней  указывает диапазон байт, в котором на данный корень есть ссылки. GC, находясь в определенном месте при вызове, смотрит, какие корни действительны в этой точке вызова, а какие - нет, именно по этой таблице, генерируемой JIT-компилятором Наверное это вопрос, а не критика.  (пример из рихтера) Код public static class Program {     public static void Main() {         // Создание объекта Timer, вызывающего метод TimerCallback          // каждые 2000 миллисекунд.          System.Threading.Timer t = new System.Threading.Timer(TimerCallback, null, 0, 2000);         // Ждем, когда пользователь нажмет Enter.          Console.ReadLine();     }     private static void TimerCallback(Object o) {         // Отображение даты/времени вызова этого метода.          Console.WriteLine("In TimerCallback: " + DateTime.Now);         // Принудительный вызов сборщика мусора в этой программе.          GC.Collect();     } } Обычный режим. JIT-сгенирил все свою лабуду и корни в том числе. После вызова GC.Collect(); сборщик удалит объект (речь идет о Timer), так как при поиске ссылок он не найдет ничего. Режим отладки. JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать, чтобы при вызове GC.Collect(); сборщик увидел что есть ссылки и не удалил объект до конца метода мэин. По простому так. JIT не занимается поиском смертников, для этого и создан сборщик и он управляет жизнью объекта так сказать.

Автор: WarHog 5.2.2009, 14:28

Цитата(emmanuil @ 5.2.2009,  14:17) Обычный режим. JIT-сгенирил все свою лабуду и корни в том числе. ... Режим отладки. JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать... emmanuil, а разве в обычном режиме таблица корней не создается? ;)

Автор: PashaPash 5.2.2009, 15:12

emmanuil,  За временем жизни объекта следит GC. А что именно в данном месте кода является корнем - определяет JIT. Т.е. именно JIT при отладке продлевает время жизни переменной до конца метода. Умирает (не используется) переменная - объект потенциально может быть собран GC. GC.KeepAlive всего-лишь говорит JIT что "вот тут переменная еще используется". Вот вопрос топикастера: Цитата(v00d00 @  2.2.2009,  12:54 ) Что  делает метод GC.KeepAlive() я могу понять по документации, меня интересует как метод, который вызывается после завершения программы может препятсявовать удалению объекта сборщиком мусора? Сложилось впечатление что это деректива препроцессору... Ответ на него - метод явно указывает JIT что надо продлить время жизни переменной до это этой строки. Продление времени жизни переменной вызывает продление времени жизни объекта, на который она ссылается. Человек хотел подробностей  Цитата(emmanuil @  5.2.2009,  14:17 ) JIT не занимается поиском смертников, для этого и создан сборщик и он управляет жизнью объекта так сказать. JIT отдает сборщику указание что вот с этого места XXX больше не корень. Т.е. он определяет "не смертников" в пределах метода

Автор: emmanuil 5.2.2009, 16:25

WarHog, а ты читай внимательнее: JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать... Таблица то создается, но одна. А в отладке создается еще и внутренняя.

Автор: WarHog 5.2.2009, 16:31

emmanuil, эта внутренняя таблица с корнями и их байтовыми смещениями создается всегда, независимо от того, release или debug версия. это влияет только на байтовые смещения корней

Автор: emmanuil 5.2.2009, 16:45

То Цитата(PashaPash @  5.2.2009,  08:38 ) Насколько я знаю, сборщик мусора за временем жизни объектов не следит. то Цитата(PashaPash @  5.2.2009,  13:12 ) За временем жизни объекта следит GC. Ну а я разве говорил, что сборщик делает корни и все такое? И JIT никого не информирует. Перевел в машинный, свои дела сделал всякие, указал корни и видимости, а вот удалять или нет объект решает сам сборщик, проходит, маркирует, удаляет, а потом воскресить даже может, там он не просто тупа проходит по корням как ты говорил, проходов несколько может быть. Цитата(PashaPash @  5.2.2009,  13:12 ) JIT отдает сборщику указание что вот с этого места XXX больше не корень. Т.е. он определяет "не смертников" в пределах метода  Ну не указания а что-то типо метки, что вот от сюда до сюда видно а дальше нет. А вот если на этот локально созданный объект начнет ссылаться поле из другого класса? Вот тут и считает сборщик ссылки. JIT генерирует код один раз, а сборщик работает всегда. Цитата(PashaPash @  5.2.2009,  13:12 ) Ответ на него - метод явно указывает JIT что надо продлить время жизни переменной до это этой строки. Продление времени жизни переменной вызывает продление времени жизни объекта, на который она ссылается. Человек хотел подробностей  а вот и подробности. Цитата(emmanuil @  3.2.2009,  08:36 ) Он не подбирается сборщиком, потому что на него ссылка имеется при вызове метода GC.KeepAlive(mt). Вот поэтому он и живет до конца приложения, т.е. пока не закроется главная форма в твоем случае.А метод этот делает ссылку на указанный объект, делая его недоступным для сборщика мусора с момента начала текущей процедуры до вызова этого метода. Чтобы лучше понять это, нужно понять принципы работы GC. Цитата(emmanuil @  4.2.2009,  15:59 ) Если бы ты использовал объект после закрытия гл. формы, то все время работы приложения он бы не уничтожился, так как на него будет ссылка. Цитата(emmanuil @  4.2.2009,  16:46 )  Переменная всего лишь хранит в себе ссылку, а сам объект лежит не в стеке, а в куче. После создания мутекса при отсутствии GC.KeepAlive(mt); на созданный объект больше не ссылается не одна переменная и поэтому сборщик уничтожает объект за ненадобностью. Цитата(PashaPash @  5.2.2009,  13:12 ) JIT при отладке продлевает время жизни переменной до конца метода Не переменной а объекта, путем создания внутренней таблицы и переменная тут не причем.

Автор: PashaPash 5.2.2009, 16:48

Цитата(emmanuil @  5.2.2009,  16:25 ) WarHog, а ты читай внимательнее: JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать... Таблица то создается, но одна. А в отладке создается еще и внутренняя.  Не создается никакой таблицы "искуственных ссылок". JIT создает ровно одну таблицу вида: F0 7B          | 000B        reg EDI becoming live 5A             | 000D        reg EBX becoming live F0 42          | 0017        reg EAX becoming live 72             | 0019        reg ESI becoming live 4A             | 001B        reg ECX becoming live F0 03          | 0026        reg EAX becoming dead ... 06             | 0043        reg EAX becoming dead 08             | 0043        reg ECX becoming dead 10             | 0043        reg EDX becoming dead 4C             | 0047        reg ECX becoming live 0E             | 004D        reg ECX becoming dead 30             | 004D        reg ESI becoming dead F1 1B          | 0060        reg EBX becoming dead 38             | 0060        reg EDI becoming dead FF             |  В дебаге dead в этой таблице смещаются ближе к концу - вот и весь фокус. GC работает c кодом уже после JIT, в нем нет никаких "переменных" и продлевать нечего. Есть стек и регистры и инфа от JIT корень/не корень.

Автор: emmanuil 5.2.2009, 16:53

Цитата(WarHog @  5.2.2009,  14:31 ) emmanuil, эта внутренняя таблица с корнями и их байтовыми смещениями создается всегда, независимо от того, release или debug версия. это влияет только на байтовые смещения корн с термином ошибся, согласен. выражал что исскуственные ссылки. Цитата(emmanuil @  5.2.2009,  14:25 ) JIT-сгенирил все свою лабуду и корни в том числе, плюс сгенерил еще и внутреннюю таблицу, исскуственные ссылки так сказать... Добавлено через 2 минуты и 25 секунд Так ты уже определись  Цитата(PashaPash @  5.2.2009,  14:48 ) GC работает c кодом уже после JIT, в нем нет никаких "переменных" и продлевать нечего или Цитата(PashaPash @  5.2.2009,  13:12 ) Ответ на него - метод явно указывает JIT что надо продлить время жизни переменной до это этой строки. Продление времени жизни переменной вызывает продление времени жизни объекта, на который она ссылается. Человек хотел подробностей  Добавлено через 11 минут и 56 секунд Цитата(PashaPash @  5.2.2009,  14:48 ) Не создается никакой таблицы "искуственных ссылок" Термином как уже говорил подобрал неудачный. Сдвиг байтов - а я назвал исскуственные ссылки.

Автор: PashaPash 5.2.2009, 17:06

Цитата(emmanuil @  5.2.2009,  16:45 ) Ну а я разве говорил, что сборщик делает корни и все такое? И JIT никого не информирует. Перевел в машинный, свои дела сделал всякие, указал корни и видимости, а вот удалять или нет объект решает сам сборщик, проходит, маркирует, удаляет, а потом воскресить даже может, там он не просто тупа проходит по корням как ты говорил, проходов несколько может быть. Нет, не решает. Если объект в 0 поколении, без финализера, и нет живых корней - то его удалит всегда. Есть корни или нет в конкретной точке  - решает JIT. Продлевает их в debug - тоже JIT. Цитата(emmanuil @  5.2.2009,  16:45 ) Не переменной а объекта, путем создания внутренней таблицы и переменная тут не причем. Приведи, пожалуйста, хоть какое-то подтверждение существования дополнительной внутренней таблицы ссылок. Цитата(emmanuil @  5.2.2009,  16:45 ) Он не подбирается сборщиком, потому что на него ссылка имеется при вызове метода GC.KeepAlive(mt). Вот поэтому он и живет до конца приложения, т.е. пока не закроется главная форма в твоем случае.А метод этот делает ссылку на указанный объект, делая его недоступным для сборщика мусора с момента начала текущей процедуры до вызова этого метода. Чтобы лучше понять это, нужно понять принципы работы GC. Да, все отлично, используется переменная и все такое. Я как бы и не пытался это опровергнуть. Вот только спорим мы вот об этом: Цитата(PashaPash @  4.2.2009,  21:14 ) В debug JIT продлевает время жизни переменной до ее scope - чтобы в отладке можно было посмотреть значение после последнего использования. В release время жизни значительно сокращается smile  Цитата(emmanuil @  5.2.2009,  05:44 ) На сколько я знаю, то JIT это способ компиляции и JIT  компиляторы. А за временем жизни объектов следит CLR - сборщик мусора. Как с этим справляется IDE мне доподленно не известно, возможно для переменных хранит ссылки на них во время отладки для показана сведений по ним.  Я подробно расписал как и кто справляется с "этим". Дал линк, пару раз еще тут подробно описал. А ты все еще утверждаешь что  Цитата(emmanuil @  5.2.2009,  16:45 ) Не переменной а объекта, путем создания внутренней таблицы и переменная тут не причем. JIT явно говорит GC что конкретный регистр (переменная) или кусок стека "не корень со строчки XXX". Говорит в терминологии alive/dead. Т.е. он натурально обманывает GC и говорит что значение в регистре - переменная ссылочного типа - живет дольше чем на самом деле должна. И не надо тут никакие внутренние временные таблицы ссылок притягивать за уши  Добавлено через 1 минуту и 9 секунд Ок, пофлеймили, размяли пальцы, работаем дальше  Добавлено через 3 минуты и 20 секунд Цитата(emmanuil @  5.2.2009,  16:53 ) GC работает c кодом уже после JIT, в нем нет никаких "переменных" и продлевать нечего Цитата(emmanuil @  5.2.2009,  16:53 ) Ответ на него - метод явно указывает JIT что надо продлить время жизни переменной до это этой строки. Продление времени жизни переменной вызывает продление времени жизни объекта, на который она ссылается. Человек хотел подробностей  JIT видит код и до себя и после себя  И продлевает время жизни того, во что превращаются переменные, в том, во что он их превращает  GC видит только код после JIT, и полностью верит JIT в плане того, что в данный момент живое, а что нет. И самостоятельно выбор не делает, тупо собирает и все

Автор: emmanuil 5.2.2009, 17:44

Цитата(PashaPash @  5.2.2009,  15:06 ) Приведи, пожалуйста, хоть какое-то подтверждение существования дополнительной внутренней таблицы ссылок. На счет этого писал. Цитата(PashaPash @  5.2.2009,  15:06 ) JIT явно говорит GC что конкретный регистр (переменная) или кусок стека "не корень со строчки XXX". Говорит в терминологии alive/dead. Т.е. он натурально обманывает GC и говорит что значение в регистре - переменная ссылочного типа - живет дольше чем на самом деле должна. И не надо тут никакие внутренние временные таблицы ссылок притягивать за уши  Как уже писал делает исскуственные ссылки, дабы продлить жизнь. Если корень перестает быть корнем, это не занчит что именно там удалится объект. Корень это всего лишь адрес на объект в куче. ссылаться могут многие переменные на один объект. При сборе сборщик проверяет корни и маркирует. И только после это немаркированные объекты могут быть удалены.

Автор: PashaPash 5.2.2009, 18:24

Цитата(emmanuil @  5.2.2009,  17:44 ) Как уже писал делает исскуственные ссылки, дабы продлить жизнь. Более точно - продлевает жизнь настоящей ссылки. Он не создает доп. копию и не создает никаких внутренних таблиц. Ссылка как лежала в регистре, так и лежит, только GC не уведомляют вовремя что регистр уже не корень. Цитата(emmanuil @  5.2.2009,  17:44 ) Если корень перестает быть корнем, это не занчит что именно там удалится объект. Корень это всего лишь адрес на объект в куче. ссылаться могут многие переменные на один объект. При сборе сборщик проверяет корни и маркирует. И только после это немаркированные объекты могут быть удалены. Ну чтобы совсем точно - если в умершем корне лежала единственная ссылка на объект нулевого поколения и наступила сборка мусора [тут стандартные условия при которых объекты не удаляются] объект будет удален. Мы как бы не о сборке мусора спорим, которую все давно в рихтере прочитали. Спорим о том, почему именно переменные-ссылки и объекты, на которые они ссылаются, в дебаге доживают до конца метода, когда формально самих ссылок после последнего использования уже нет. Я утверждаю что этим занимается JIT, обманывая сборщик мусора и не показывая ему настоящее положение вещей. Ты чем-то не согласен с этим утверждением и пытаешься пропихнуть модель с внутренними таблицами и искуственными ссылками.  Продолжаем..

Автор: emmanuil 5.2.2009, 18:58

Цитата(PashaPash @  5.2.2009,  16:24 ) только GC не уведомляют вовремя что регистр уже не корень. Да сборщика вообще не уведомляют. Он сам проверяет корни когда ничинается сборка. Цитата(PashaPash @  5.2.2009,  16:24 ) Ну чтобы совсем точно - если в умершем корне лежала единственная ссылка на объект нулевого поколения и наступила сборка мусора [тут стандартные условия при которых объекты не удаляются] объект будет удален Ну а кто тут с тобой спорит. Но. То ты говоришь что JIT рулит временем жизни, а теперь что условия стандартные и умерший корень...JIT сделал корень, обозначил отсюда до сюда живой и все, а там уже сборщик сам проверяет ссылки на объект. и если в одном месте корень умер, то может быть живой в другом месте и это проверит уже сборщик при обходе и никакой ни JIT. Цитата(PashaPash @  5.2.2009,  16:24 ) Я утверждаю что этим занимается JIT, обманывая сборщик мусора и не показывая ему настоящее положение вещей. Ты чем-то не согласен с этим утверждением и пытаешься пропихнуть модель с внутренними таблицами и искуственными ссылками.  Продолжаем..  Вот с таблицами я ошибся, уже писал что я имел в виду. Цитата(PashaPash @  5.2.2009,  16:24 ) . Спорим о том, почему именно переменные-ссылки и объекты, на которые они ссылаются, в дебаге доживают до конца метода, когда формально самих ссылок после последнего использования уже нет.   спорим не поэтому, потому как я писал что обманывает сам себя, объяснил с таблицами. а спорим потому что ты все никак прочитатьне можешь Цитата(emmanuil @  5.2.2009,  14:53 ) Термином как уже говорил подобрал неудачный. Сдвиг байтов - а я назвал исскуственные ссылки. Я начал спор не поэтому, я честно сказал что доподленно незнаю как в дебаге там и почему. Цитата(PashaPash @  5.2.2009,  08:38 ) Насколько я знаю, сборщик мусора за временем жизни объектов не следит. но потом ты всетаки сказал Цитата(PashaPash @  5.2.2009,  13:12 ) За временем жизни объекта следит GC Цитата(PashaPash @  5.2.2009,  08:38 )  И именно JIT дает GC список смертников - GC Info И вот из-за этого тоже. ну еще раз напишу, JIT сборщику никакого списка не дает, он делает корни и видимости а сборщик уже сам там разбирается кого надо удалять а кого нет. Потом ты вроде как со всем этим согласился и плавно переместился на мою ошибочку про таблицы, но и там я ошибся только в терминологии и не вел себя как флюгер: Цитата(PashaPash @  5.2.2009,  08:38 ) Насколько я знаю, сборщик мусора за временем жизни объектов не следит. но потом ты всетаки сказал Цитата(PashaPash @  5.2.2009,  13:12 ) За временем жизни объекта следит GC Дискутировать дальше не вижу смысла, так как ты уже начал из-за терминов спорить. Тема закрыта.

Автор: PashaPash 5.2.2009, 20:04

Не надо даблквотинга. Все равно ведь флеймовая тема.   Лучше вот на мой единственный вопрос на форуме ответь, про XmlSerializer :(

Автор: v00d00 6.2.2009, 13:16

Не знаю, имеет ли смысл здесь еще постить, однако провел эксперимент: объявил функцию: Код private static void KeepAlive(object o)         {             o.GetHashCode();         } в релизной версии результат такой же что и от применения аналогичной функции GC.KeepAlive() Сборшик анализируте не только сегмент стека, но и сегмент кода. Это все что я хотел узнать.

Автор: Partizan 6.2.2009, 13:21

v00d00, имхо не обман сборщика мусора, а просто сборщик мусора не будет удалять объект, потому что он реально используется...

Автор: emmanuil 6.2.2009, 13:27

Цитата(Partizan @  6.2.2009,  11:21 ) v00d00, имхо не обман сборщика мусора, а просто сборщик мусора не будет удалять объект, потому что он реально используется... Вот именно. Сборщик просто видит, что объект еще дальще используется и не удаляет его.

Автор: v00d00 6.2.2009, 13:29

Да объект используется, также как и в методе GC.KeepAlive(). Собственно вот коментарий от разработчиков Цитата References the specified object, which makes it ineligible for garbage collection from the start of the current routine to the point where this method is called.

Автор: PashaPash 6.2.2009, 14:34

Цитата(v00d00 @  6.2.2009,  13:16 ) Сборшик анализируте не только сегмент стека, но и сегмент кода. Это все что я хотел узнать.  Уже много на эту тему спорили выше  Сборщик мусора не анализирует код. Он получает готовый результат анализа от JIT.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)