emmanuil, а разве в обычном режиме таблица корней не создается? ;)

emmanuil, 
За временем жизни объекта следит GC. А что именно в данном месте кода является корнем - определяет JIT. Т.е. именно JIT при отладке продлевает время жизни переменной до конца метода. Умирает (не используется) переменная - объект потенциально может быть собран GC. GC.KeepAlive всего-лишь говорит JIT что "вот тут переменная еще используется".
Вот вопрос топикастера:

Ответ на него - метод явно указывает JIT что надо продлить время жизни переменной до это этой строки. Продление времени жизни переменной вызывает продление времени жизни объекта, на который она ссылается. Человек хотел подробностей 

JIT отдает сборщику указание что вот с этого места XXX больше не корень. Т.е. он определяет "не смертников" в пределах метода 

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

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

То

то

Ну а я разве говорил, что сборщик делает корни и все такое? И JIT никого не информирует. Перевел в машинный, свои дела сделал всякие, указал корни и видимости, а вот удалять или нет объект решает сам сборщик, проходит, маркирует, удаляет, а потом воскресить даже может, там он не просто тупа проходит по корням как ты говорил, проходов несколько может быть.
Ну не указания а что-то типо метки, что вот от сюда до сюда видно а дальше нет. А вот если на этот локально созданный объект начнет ссылаться поле из другого класса? Вот тут и считает сборщик ссылки. 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 корень/не корень.

с термином ошибся, согласен. выражал что исскуственные ссылки.


Добавлено через 2 минуты и 25 секунд
Так ты уже определись 

или


Добавлено через 11 минут и 56 секунд
Термином как уже говорил подобрал неудачный. Сдвиг байтов - а я назвал исскуственные ссылки.

Нет, не решает. Если объект в 0 поколении, без финализера, и нет живых корней - то его удалит всегда. Есть корни или нет в конкретной точке  - решает JIT. Продлевает их в debug - тоже JIT.

Приведи, пожалуйста, хоть какое-то подтверждение существования дополнительной внутренней таблицы ссылок.


Да, все отлично, используется переменная и все такое. Я как бы и не пытался это опровергнуть. Вот только спорим мы вот об этом:


Я подробно расписал как и кто справляется с "этим". Дал линк, пару раз еще тут подробно описал. А ты все еще утверждаешь что 

JIT явно говорит GC что конкретный регистр (переменная) или кусок стека "не корень со строчки XXX". Говорит в терминологии alive/dead. Т.е. он натурально обманывает GC и говорит что значение в регистре - переменная ссылочного типа - живет дольше чем на самом деле должна. И не надо тут никакие внутренние временные таблицы ссылок притягивать за уши 

Добавлено через 1 минуту и 9 секунд
Ок, пофлеймили, размяли пальцы, работаем дальше 

Добавлено через 3 минуты и 20 секунд


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

На счет этого писал.
Как уже писал делает исскуственные ссылки, дабы продлить жизнь.
Если корень перестает быть корнем, это не занчит что именно там удалится объект. Корень это всего лишь адрес на объект в куче. ссылаться могут многие переменные на один объект. При сборе сборщик проверяет корни и маркирует. И только после это немаркированные объекты могут быть удалены.


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

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

Ну чтобы совсем точно - если в умершем корне лежала единственная ссылка на объект нулевого поколения и наступила сборка мусора [тут стандартные условия при которых объекты не удаляются] объект будет удален. Мы как бы не о сборке мусора спорим, которую все давно в рихтере прочитали. Спорим о том, почему именно переменные-ссылки и объекты, на которые они ссылаются, в дебаге доживают до конца метода, когда формально самих ссылок после последнего использования уже нет. Я утверждаю что этим занимается JIT, обманывая сборщик мусора и не показывая ему настоящее положение вещей. Ты чем-то не согласен с этим утверждением и пытаешься пропихнуть модель с внутренними таблицами и искуственными ссылками.  Продолжаем.. 

Да сборщика вообще не уведомляют. Он сам проверяет корни когда ничинается сборка.
Ну а кто тут с тобой спорит. Но. То ты говоришь что JIT рулит временем жизни, а теперь что условия стандартные и умерший корень...JIT сделал корень, обозначил отсюда до сюда живой и все, а там уже сборщик сам проверяет ссылки на объект. и если в одном месте корень умер, то может быть живой в другом месте и это проверит уже сборщик при обходе и никакой ни JIT.
Вот с таблицами я ошибся, уже писал что я имел в виду.
 спорим не поэтому, потому как я писал что обманывает сам себя, объяснил с таблицами. а спорим потому что ты все никак прочитатьне можешь

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

И вот из-за этого тоже. ну еще раз напишу, JIT сборщику никакого списка не дает, он делает корни и видимости а сборщик уже сам там разбирается кого надо удалять а кого нет. Потом ты вроде как со всем этим согласился и плавно переместился на мою ошибочку про таблицы, но и там я ошибся только в терминологии и не вел себя как флюгер:
но потом ты всетаки сказал

Дискутировать дальше не вижу смысла, так как ты уже начал из-за терминов спорить. Тема закрыта.

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

Не знаю, имеет ли смысл здесь еще постить, однако провел эксперимент:

объявил функцию:


в релизной версии результат такой же что и от применения аналогичной функции GC.KeepAlive()

Сборшик анализируте не только сегмент стека, но и сегмент кода. Это все что я хотел узнать.

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

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