Тут вопросик общего плана. Программа создает Кучу и Стек.
Куча умерает ли вместе с программой????
А GAC чистит только стек????

И каким методом можна автоматически запускать Garbige Collector в нужный момент времени...

Конечно. Об этом заботиться среда .Net 

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


Это сообщение отредактировал(а) ivashkanet - 11.7.2007, 17:09

А что там чистить в Куче и Что GAC чистит в стеке????

Стек - вообще интересное понятие. Вот кто например может мне сказать, почему массивы хранятся вне памяти метода (т.е. в куче), однако элементы массива являются value type? Это что, означает что есть некая память называемая стековой, но таковой не являющаяся?

  

   и как тогда мона в этом разобратся?????
   как минимум нужен отдельный форум по GAC.... 

Добавлено через 1 минуту и 5 секунд

он сам пройдется, освободит файл и вырубиться7???  

Я могу 
По той же причине в куче хранятся, по которой и класс типа

массивы, это те же классы, содержащие свойства, методы и поля...


да нет. есть просто стековая память и куча. В стековой памяти хранятся value-объекты и ссылки на reference-объекты. Когда выходим из метода стек чистится полностью, т.е. ячейки с value-объектами очищаются и ячейки со ссылками на reference-объекты очищаются тоже. В итоге мы имеем reference-объекты, на которые никто не указывает (недостижимые объекты, добыча GC)
В случае с массивом, ссылка на него изчезнет, а массив - останется в куче до сборки мусора...

Azzdorf могу посоветовать почитать этот топик, может что-то прояснится по GC

И не путай GC с GAC - это разные вещи   

Противоречие: стек чистится = вся память занятая под стек очищается = все объекты выделенные на стековой памяти удаляются
Вопрос 1: куда при этом деваются объекты (структуры, инты и т.п.) хранимые в массиве? Они ведь value type а не reference type, и в отличие от массива должны быть выделены на стеке. Почему же они остаются жить после очистки стековой памяти?
Вопрос 2: как GC рассматривает объекты, созданные на стеке но хранимые в массиве? Как часть reference-типа? То есть попадают ли они в поколения, собираемые GC?  

З.Ы. Судя по тому что я видел в .NET Memory Profiler, даже простейшие int-ы собираются GC вплоть до 1-2 поколений сборки мусора. Но это объяснимо в случае если они боксятся. В случае же массивов, как и generic-ов заявляемые мелкософтом возможности гарантируют что простейшие типы не будут бокситься, если они лежат в массиве или одной из generic-коллекций (кстати, все generic-коллекции так или иначе юзают массивы). Что же тогда на самом деле происходит с элементами массива, под какую категорию они подпадают? Ау, Рихтер, где ты?   

Это как?

Это так:


Что есть элемент массива array? Это value type (и тогда он физически расположен на стеке) или reference type (лежит в куче) ?

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

нет противоречия если мы в ф-ции создаем массив целых чисел
то в стеке создается переменная 32 бита для хранения значени переменной arrInt. А значением этой переменной будет адрес блока памяти, выделенного под массив (под десять целых чисел + системмные блоки класса)
После выхода из ф-ции переменная arrInt сотрется, а блок памяти для массива в куче - останется.

Ответ 1  

 эти объекты размещаются в куче изначально, в ней и хранятся, уничтожаются сборщиком мусора. Поэтому "они остаются жить после очистки стековой памяти". Все то же самое, как в случае с массивом arrInt... Еще раз повторю:в стеке хранится (и после выхода из ф-ции удаляется) только ссылка на массив! 
Если структура, инт и что угодно из value-объектов создаются сами по себе, то они размещаются и хранятся в стеке, благо посчитать требуемый ими объем памяти - несложно. Если они - члены ссылочного типа, то размещаться они будут в куче, в блоке памяти, выделенном под ссылочный объект. Если у структуры есть поле ссылочного типа, то в стеке будет размещена вся структура (под член ссылочного типа будет выделено 4 байта, для хранения ссылки на кучу). Когда стек будет очищаться - в куче останется недостижимый объект (бывший член структуры)

Ответ 2 
 честно говоря не понял, что ты имеешь в виду... 
 в поколения может попасть все, что подвластно сборщику мусора, т.е. все, что хранится в куче. А попадет реально, или нет - это уже у GC спрашивать нужно.  Но если тип поддерживает финализатор - 100% попадет.

Ответ 3 (на "З.Ы.")
Мне кажется, что ты зря связываешь понятия поколения с боксингом, + еще куча со стеком... 
Главное - это к какому типу ссылочного объекта принадлежат простейшие. Ну и от системмных условий. От этого зависит как часто и насколько тщательно будет сборщик мусора собирать мусор. А боксинг используется только при приведении типов. Конечно, и массивы и генерики - типизированы, поэтому они не нуждаются в боксинге.
Но это не важно для нашего вопроса: незабоксенные инты (члены массива) будут находится в куче также, как забоксенные, как вообще все элементы ссылочных типов.... И когда GC рещит "грохнуть" объект в куче, он "грохнет" его вместе со всеми его членами, даже если там 10 незабоксенных и 5 забоксенных.

Azzdorf вопрос непосредственного использования GC - зависит от ситуации. Но "по статистике"   применяется очень редко... Гораздо реже IDisposable. Вот это действительно, на что нужно обратить внимание в первую очередь...

Динамическое выделение стековой памяти, стековые массивы - это оптимизация производительности прежде всего. Тоже - непростая и спорная тема... 

Кто и когда говорил, что экземпляры value types всегда хранятся в стеке?

В случае с массивом имеет место как раз второй вариант.

mr.DUDA, уж не завладел ли кто твоим аккаунтом, если ты такие вещи спрашиваешь? 


С пулами объектов есть серьёзные проблемы. С region inference тоже.

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

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

согласен что спорная, но не есть ли оптимальная робота программы с памятю - одним из столпов професионального программирования и создания ефективных преложений????  и стоит ли к этому стремится или это пустая трата времени???