Автоматическое управление памятью в .NET
От: Игорь Ткачев Россия linq2db.com
Дата: 16.01.03 05:18
Оценка: 985 (26) -1
Статья:
Автоматическое управление памятью в .NET
Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.


Авторы:
Игорь Ткачев

Аннотация:
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.
Если нам не помогут, то мы тоже никого не пощадим.
Почему в C# тесте явно вызывается GC.Collect()?
От: alexkro  
Дата: 30.01.03 07:57
Оценка:
Это делает тест не очень "чистым". Хотелось бы посмотреть, как GC ведет себя в "естественных" условиях.
Дефрагментация
От: Yury_Malich Германия http://malich.ru
Дата: 27.01.03 08:43
Оценка:
[quote]Для хранения объектов CLR использует хип, подобный хипу C++, за тем важным исключением, что хип CLR не фрагментирован[/quote]
Явно противоречит
[quote] Другими словами, объекты, пережившие две сборки мусора, остаются в хипе навсегда и GC не занимается их дефрагментацией.[/quote]
Так фрагментирована всё-таки куча или нет?
"Практика — критерий истины" (c) Маркс
Поколение 2
От: Тестовый юзер  
Дата: 17.01.03 05:18
Оценка:
А как стыкуется вот эта фраза:
"объекты, пережившие две сборки мусора, остаются в хипе навсегда и GC не занимается их дефрагментацией"
и фраза из статьи
ms-help://MS.MSDNQTR.2002OCT.1033/cpguide/html/cpconautomaticmemorymanagement.htm
"If this does not reclaim enough memory, the garbage collector can perform a collection of generations 2, 1, and 0."
Т.е объект поколения 2 все же может подметен из хипа?
Re: Дефрагментация
От: CooLer Россия http://bestsoft.far.ru
Дата: 21.02.03 01:51
Оценка:
Никакого противоречия тут нет.
Первая фраза означает, что после сборки куча дефрагментируется и все объекты сдвигаются к началу.
Вторая, что только то, что GC просто игнорирует объекты из второго поколения.
"Выше голову" — сказл палач, надевая петлю
Re: Поколение 2
От: CooLer Россия http://bestsoft.far.ru
Дата: 21.02.03 01:46
Оценка:
GC.Collect() как раз выметает всё. Но это если вызов GC форсировать самостоятельно.
"Выше голову" — сказл палач, надевая петлю
Re: Почему в C# тесте явно вызывается GC.Collect()
От: CooLer Россия http://bestsoft.far.ru
Дата: 21.02.03 01:41
Оценка:
Ведёт себя хорошо.
"Выше голову" — сказл палач, надевая петлю
Re: Поколение 2
От: Тестовый юзер  
Дата: 27.02.03 01:13
Оценка:
А если судить по MSDN, то когда память кончилась и освобожление более молодых поколений не дает требуемого количества памяти.
Re: Почему в C# тесте явно вызывается GC.Collect()?
От: IT Россия linq2db.com
Дата: 18.07.03 16:28
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Это делает тест не очень "чистым". Хотелось бы посмотреть, как GC ведет себя в "естественных" условиях.


Если не вызывать Collect, то .NET будет ещё дальше впереди.
Впрочем, это зависит от наличия памяти на машине и размера выделяемых блоков.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Дефрагментация
От: IT Россия linq2db.com
Дата: 18.07.03 16:33
Оценка:
Здравствуйте, CooLer, Вы писали:

CL>Первая фраза означает, что после сборки куча дефрагментируется и все объекты сдвигаются к началу.

CL>Вторая, что только то, что GC просто игнорирует объекты из второго поколения.

Да, но всё же GC.Collect() чистит и второе поколение. Данная фраза относится к автоматическому режиму GC, когда в её работу не вмешиваются.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Поколение 2
От: IT Россия linq2db.com
Дата: 18.07.03 16:38
Оценка:
Здравствуйте, Тестовый юзер, Вы писали:

ТЮ>Т.е объект поколения 2 все же может подметен из хипа?


Вполне возможно. Судя по тестам, GC не спешит чистить второе поколение, но вполне возможны ситуации, когда это может произойти. Ни подтвердить, ни опровергнуть это нельзя, т.к. во-первых, доступные исходники Rotor'а, особенно по части GC, весьма отличаются от того что на самом деле происходит в CLR, а во-вторых, MS постоянно совершенствует CLR и возможно в версии 1.1 фреймворка что-то уже и изменилось.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Автоматическое управление памятью в .NET
От: ynblpb  
Дата: 09.01.04 14:12
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:

ИТ>Статья:



ИТ>Авторы:

ИТ> Игорь Ткачев

ИТ>Аннотация:

ИТ>Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.



class Class1
{
    class TestClass
    {
        public override string ToString()
        {
            return "Test Object No " + objectNo;
        }
        public TestClass()
        {
            objectNo++;
        }
        static int objectNo = 0;
    }

    // «слабая» ссылка
    WeakReference wr = new WeakReference(null);

    // Возвращает ссылку на объект,
    // при необходимости создаёт новый
    TestClass GetRef()
    {
        // Если объект уже создан и всё ещё жив,
        // то мы можем получить ссылку на него через Target
        TestClass tc = (TestClass)wr.Target;
        if (tc == null)
        {
            tc = new TestClass();
            wr.Target = tc;
        } 
        return tc;
    }

    public void Test()
    {
        // Получаем ссылку на объект
        object obj = GetRef();

        // Вызываем сборщик мусора,
        // но объект не будет удалён, 
        // т.к. существует «сильная» ссылка obj
        GC.Collect();

        // Печатаем "Test Object No 1"
        Console.WriteLine(GetRef());

        // удаляем «сильную» ссылку
        obj = null;

        // Печатаем опять "Test Object No 1",
        // т.к. сборщик мусора не вызывался и мы можем
        // получить объект через «слабую» ссылку
        Console.WriteLine(GetRef());

        // Вызываем сборщик мусора ещё раз
        GC.Collect();

        // На этот раз печатаем "Test Object No 2",
        // сборщик мусора удалил старый объект,
        // и вызоа GetRef создаст новый
        Console.WriteLine(GetRef());
    }
}


Объясните глупому, как при вызове Console.WriteLine(GetRef()); будет вызываться
public override string ToString()

? Или что вообще будет вызываться? Другими словами: точно ли печататься вообще что-либо будет?
можть и я вам когда-нибудь помогу
Re[2]: Автоматическое управление памятью в .NET
От: IT Россия linq2db.com
Дата: 09.01.04 14:46
Оценка:
Здравствуйте, ynblpb, Вы писали:

Y>Объясните глупому, как при вызове Console.WriteLine(GetRef()); будет вызываться

Y>
Y>public override string ToString()
Y>

Y>? Или что вообще будет вызываться? Другими словами: точно ли печататься вообще что-либо будет?

А в чём проблема? Берёт и вызывает. ToString — это метод object, а всё объекты в .NET происходят от object.
Вот что происходит в результате (TextWriter.cs из исходников Ротора):

public virtual void Write(Object value) {
    if (value != null) {
        IFormattable f = value as IFormattable;
        if (f != null)
            Write(f.ToString(null, FormatProvider));
        else
            Write(value.ToString());
    }
}
Если нам не помогут, то мы тоже никого не пощадим.
Re: Автоматическое управление памятью в .NET
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.01.04 15:09
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:

Очень хотелось бы получить полный ответ на
http://www.rsdn.ru/Forum/Message.aspx?mid=415352&amp;only=1
Автор: Serginio1
Дата: 20.10.03

И как сие избежать. Памяти предостаточно, но такое впечатление, что GC следит за объектами при смене ссылок на них.
и солнце б утром не вставало, когда бы не было меня
Re: Где посмотреть на структуру графа достижимых объектов?
От: Аноним  
Дата: 13.07.04 10:09
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:
Искал в sscli не нашел.
Re[2]: Где посмотреть на структуру графа достижимых объектов
От: IT Россия linq2db.com
Дата: 13.07.04 23:38
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, Игорь Ткачев, Вы писали:

А> Искал в sscli не нашел.

Да всё вроде там в C++ модулях. Только без пузыря там не разобраться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Автоматическое управление памятью в .NET
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.10.05 08:22
Оценка:
Здравствуйте, ynblpb, Вы писали:

Y>Объясните глупому, как при вызове Console.WriteLine(GetRef()); будет вызываться

Y>
Y>public override string ToString()
Y>

Y>? Или что вообще будет вызываться? Другими словами: точно ли печататься вообще что-либо будет?
RTFM Console.WriteLine(ojbect value):

Remarks
If value is a null reference (Nothing in Visual Basic), only the line terminator is written. Otherwise, the ToString method of value is called to produce its string representation, and the resulting string is written to the standard output stream.

1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Автоматическое управление памятью в .NET
От: Serjio Россия  
Дата: 15.07.08 12:28
Оценка:

Соответственно, если вы создаёте класс, использующий какие-либо ресурсы,
вы также должны реализовать этот интерфейс и метод Dispose в соответствии со следующими требованиями
(эти правила никак не обозначены в MSDN и взяты мной из комментариев к исходным текстам CLI):

— Подавлять вызов метода Finalize путём удаления ссылки на объект из Finalization Queue.


не совсем понятно, почему (для чего)

вызывая Dispose, мы уже сказали сами себе, что объект нам более не нужен. а значит и использовать его более не собираемся.
В реалицации метода Dispose очищать unmanaged ресурсы,
а среда, и garbage collector (при наличии деструктора в очереди) уже позаботятся об очищении своих корней
почему нет ?
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Автор: ZOI4
Дата: 28.04.12
Re[2]: Автоматическое управление памятью в .NET
От: IT Россия linq2db.com
Дата: 15.07.08 13:31
Оценка:
Здравствуйте, Serjio, Вы писали:

S>не совсем понятно, почему (для чего)


S>вызывая Dispose, мы уже сказали сами себе, что объект нам более не нужен. а значит и использовать его более не собираемся.

S>В реалицации метода Dispose очищать unmanaged ресурсы,
S>а среда, и garbage collector (при наличии деструктора в очереди) уже позаботятся об очищении своих корней
S>почему нет ?

Finalization Queue и Dispose — это два параллельных механизма. Если отработал один, то другой уже не имеет смысла. Оставление объекта в FQ приводит к тому, что он гарантированно проталкивается в следующее поколение, а следовательно в старших поколениях накапливается больше мусора, который реже чистится.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Автоматическое управление памятью в .NET
От: Аноним  
Дата: 22.07.08 10:56
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:

ИТ>Статья:

ИТ>Автоматическое управление памятью в .NET
Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.


ИТ>Авторы:

ИТ> Игорь Ткачев

ИТ>Аннотация:

ИТ>Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.

Вы пример из параграфа "Слабые ссылки" проверяли?
Re[2]: Автоматическое управление памятью в .NET
От: IT Россия linq2db.com
Дата: 22.07.08 23:16
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Вы пример из параграфа "Слабые ссылки" проверяли?


Давно это было. А что с ним не так?
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Автоматическое управление памятью в .NET
От: merk Россия  
Дата: 23.07.08 00:45
Оценка: -1
Здравствуйте, Игорь Ткачев, Вы писали:

ИТ>Статья:

ИТ>Автоматическое управление памятью в .NET
Автор(ы): Игорь Ткачев
Дата: 06.12.2002
Алгоритм работы сборщика мусора (garbage collector, далее просто GC), являющегося частью CLR, подробно описан в книге Джефри Рихтера (Jeffrey Richter) «Applied Microsoft .NET Framework Programming». Мы не будем приводить здесь столь же подробное описание этого алгоритма, но обязательно остановимся на некоторых ключевых моментах.


ИТ>Авторы:

ИТ> Игорь Ткачев


Если бы CLR не знал ничего о созданном без его участия потоке и не просканировал бы его стек, то указатель ptr1 был бы не найден и не расценен как «живой». В этом случае деструктор объекта, на который указывает ptr1, так же был бы вызван во время сборки мусора, то есть до вывода на консоль единицы.

Найдя «живой» указатель, сборщик мусора помечает объект, на который этот указатель указывает, как всё ещё используемый программой и запрашивает информацию о его структуре, чтобы в свою очередь просканировать уже этот объект на наличие указателей на другие объекты. И так далее, пока все указатели в программе не будут обработаны.

не ищет он на стеке чужих потоков живые указатели. он просто сканирует эти внешние к clr стеки, и все, что там есть, считает набором указателей. потому что не знает типов данных на этих стеках. и если такой "указатель" вдруг попадает в область кучи, да еще прям на обьект показывает, сборщик считает это указателем на данный обьект. и обьект зависает.
зияющая дыра это дыра таких систем. поскольку вдруг, и совершенно случайно здоровенный ваш массив, не будет удаляться произвольно долго. и ваша система вдруг застрянет.
потому на GC с внешним кодом нельзя делать серьезных приложений.
и тест нужно бы все таки делать со стратегией случайного захвата и освобождения блоков случайного размера, ну там плюс минус писят процентов от некоего характеристического размера.
если же начинается подкачка страниц, GC вообще становится не по себе, поскольку ему приходится по много раз переподкачивать все страницы куда отображается куча, когда он лазает по ссылкам, а потом их еще и восстанавливает. оттого он смертельно замирает.
Re[2]: Автоматическое управление памятью в .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.07.08 16:07
Оценка:
Здравствуйте, merk, Вы писали:

Вот здесь
Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.
есть статься по свежее. Там подробно рассказано о том, что и как делает GC.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Автоматическое управление памятью в .NET
От: nikov США http://www.linkedin.com/in/nikov
Дата: 24.07.08 09:38
Оценка:
Здравствуйте, merk, Вы писали:

M>не ищет он на стеке чужих потоков живые указатели. он просто сканирует эти внешние к clr стеки, и все, что там есть, считает набором указателей. потому что не знает типов данных на этих стеках. и если такой "указатель" вдруг попадает в область кучи, да еще прям на обьект показывает, сборщик считает это указателем на данный обьект. и обьект зависает.


Это ты про консервативный сборщик мусора говоришь что ли? Откуда информация, что сборщик мусора в CLR может вести себя таким образом?

M>потому на GC с внешним кодом нельзя делать серьезных приложений.


Что такое "GC с внешним кодом"?

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


С подкачкой страниц вообще все небыстро работает. А вот механизм поколений в GC как раз призван смягчить эту проблему.
Re[3]: Автоматическое управление памятью в .NET
От: merk Россия  
Дата: 24.07.08 10:58
Оценка:
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, merk, Вы писали:


M>>не ищет он на стеке чужих потоков живые указатели. он просто сканирует эти внешние к clr стеки, и все, что там есть, считает набором указателей. потому что не знает типов данных на этих стеках. и если такой "указатель" вдруг попадает в область кучи, да еще прям на обьект показывает, сборщик считает это указателем на данный обьект. и обьект зависает.


N>Это ты про консервативный сборщик мусора говоришь что ли? Откуда информация, что сборщик мусора в CLR может вести себя таким образом?


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

M>>потому на GC с внешним кодом нельзя делать серьезных приложений.

N>Что такое "GC с внешним кодом"?
с неуправляемым, в вашей терминологии.

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

N>С подкачкой страниц вообще все небыстро работает. А вот механизм поколений в GC как раз призван смягчить эту проблему.
согласен. напускать тесты сборщику, при которых начинает подкачка — не совсем правильно. это все равно что ударить его топором по голове, ипотом смотреть как он будет шевелиться.
садизм это, откровенный садизм...
Re[2]: Автоматическое управление памятью в .NET
От: nikov США http://www.linkedin.com/in/nikov
Дата: 24.07.08 16:11
Оценка:
Здравствуйте, merk, Вы писали:

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


Осмелюсь напомнить правила форума:

Падоначье, медицинское, юридическое, военное, и пр. и пр. арго не допускаются.
Не пишите сообщения только большими или только маленькими буквами.

Re[3]: Автоматическое управление памятью в .NET
От: merk Россия  
Дата: 24.07.08 16:53
Оценка: :)
Здравствуйте, nikov, Вы писали:

N>Здравствуйте, merk, Вы писали:


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


N>Осмелюсь напомнить правила форума:


N>

N>Падоначье, медицинское, юридическое, военное, и пр. и пр. арго не допускаются.
N>Не пишите сообщения только большими или только маленькими буквами.


Если сравнить "писят" и "пятьдесят", то видно что число символов сократилось почти вдвое, в то время как смысл не был утерян!
Отличная иллюстрация преимуществ функционального программирования перед всем остальным!
Re[2]: Автоматическое управление памятью в .NET
От: Serjio Россия  
Дата: 16.10.08 05:55
Оценка:
> не ищет он на стеке чужих потоков живые указатели.
> он просто сканирует эти внешние к clr стеки, и все, что там есть, считает набором указателей.
> потому что не знает типов данных на этих стеках.
> и если такой "указатель" вдруг попадает в область кучи, да еще прям на обьект показывает,
> сборщик считает это указателем на данный обьект. и обьект зависает.

не совсем понятно, на стеке ведь лежат не только 4-байтные значения.
как сканировать стек считая что там лежат указатели.
проверяя четверками байт, или проверять 4 байта смещаясь на один.
в любом случае, произвольные объекты будут расцененны как живые

либо майкрософты не так поступают, либо это индусское решение
о котором микрософты не говорят, а остальные не замечают
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Автор: ZOI4
Дата: 28.04.12
Re[3]: Автоматическое управление памятью в .NET
От: Блудов Павел Россия  
Дата: 16.10.08 09:51
Оценка:
Здравствуйте, Serjio, Вы писали:
S>не совсем понятно, на стеке ведь лежат не только 4-байтные значения.
S>как сканировать стек считая что там лежат указатели.
S>проверяя четверками байт, или проверять 4 байта смещаясь на один.
S>в любом случае, произвольные объекты будут расцененны как живые

Речь идёт об управляемом стеке. Там лежат не просто четвёрки байт, а вполне конкретные указатели или вполне конкретные цифры.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[3]: Автоматическое управление памятью в .NET
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.10.08 05:10
Оценка:
Здравствуйте, Serjio, Вы писали:

S>либо майкрософты не так поступают, либо это индусское решение

S>о котором микрософты не говорят, а остальные не замечают
Потрясает обилие сорванных покровов в комментах к этой статье. То вон Мерк рассказывал, как GC считает всё в стеке внешних потоков указателями, теперь вот индусское решение вдруг проявилось.
Поясняю концепцию управляемого кода: в нем есть полные метаданные обо всём.
В частности, распределение стека тоже полностью известно JITу. В MSIL, в отличие от x86, у метода нет возможности сказать "я занимаю 25 байт стека под свои нужды". Вместо этого метод содержит полный список переменных с их типами.
JIT просматривает этот список, и строит карту стека. На этой карте размечено, где именно лежат указатели. Причем анализируются и типы переменных. То есть, если в стеке лежит структура, некоторые из полей которой — ссылки, то эти поля попадут в карту стека.

Поэтому GC не нужно гадать, что и где лежит. Он смотрит в карту, в которой всё точно написано.
В непредусмотренное место указатель попасть не может — так устроен CLR. Верификатор тщательно следит за тем, чтобы код не поместил указатель куда не надо.
Если нужно передать указатель на управляемый объект в неуправляемый код (привет, Мерк!), то придется объект "запинить". То есть явно сказать среде "мы тут отдаем указатель во внешний код, ты пожалуйста с ним ничего не делай". С этого момента GC всё равно, где именно в неуправляемой памяти разместился этот указатель. Он просто будет одним из корней, учитываемых при сканировании.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Автоматическое управление памятью в .NET
От: AlexDP Украина  
Дата: 27.03.09 12:16
Оценка:
Здравствуйте, Игорь Ткачев, Вы писали:

ИТ>"Другими словами, объекты, пережившие две сборки мусора, остаются в хипе навсегда и GC не занимается их дефрагментацией."



В .net 2.0 осталась такая же стратегия сборки мусора?
Re[2]: Автоматическое управление памятью в .NET
От: IT Россия linq2db.com
Дата: 27.03.09 14:29
Оценка:
Здравствуйте, AlexDP, Вы писали:

ИТ>>"Другими словами, объекты, пережившие две сборки мусора, остаются в хипе навсегда и GC не занимается их дефрагментацией."


ADP>В .net 2.0 осталась такая же стратегия сборки мусора?


В данном контексте "навсегда" имеет определённые временные рамки Нулевое поколение тоже собрается, но делается это значительно реже.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Автоматическое управление памятью в .NET
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.03.09 15:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>В данном контексте "навсегда" имеет определённые временные рамки Нулевое поколение тоже собрается, но делается это значительно реже.


Второе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Автоматическое управление памятью в .NET
От: IT Россия linq2db.com
Дата: 27.03.09 15:28
Оценка:
Здравствуйте, VladD2, Вы писали:

IT>>В данном контексте "навсегда" имеет определённые временные рамки Нулевое поколение тоже собрается, но делается это значительно реже.


VD>Второе.


Или второе
Если нам не помогут, то мы тоже никого не пощадим.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.