T>>как вообще происходит "быстрое выжирание пулов поколений"
НС>Путем быстрого выделения большого количества объектов.
T>>и почему gc.collect этому "выжиранию" препятствует?
НС>Потому что останавливает выделение и дает отработать финалайзерам.
для меня лично такое- это откровенный баг: если автоматическое управление памятью с выделением памяти под большие обьекты справляется, а с выделением паняти под маленькие объекты не справляется, то это — полная ерунда ...
Re[8]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, takTak, Вы писали:
T>>>проблема в сочетании деконструктора и небольшого массива внутри объекта
НС>>Нет. Проблема в большом количестве финализаторов и быстром выжирании пулов поколений.
T>ну да, похоже на такое...
T>как вообще происходит "быстрое выжирание пулов поколений" и почему gc.collect этому "выжиранию" препятствует?
gc.collect как раз и переводит из поколения в поколение. Со старшими поколениями видно и происходит проблема с финализаторами.
Там считается если уж попал во 2 е поколение то это на долго.
А GC.WaitForPendingFinalizers(); принудительно дожидается пока все финализаторы не сработают
и солнце б утром не вставало, когда бы не было меня
Re[10]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, takTak, Вы писали:
T>для меня лично такое- это откровенный баг
Для тебя лично. Этому поведению уже 20 лет скоро.
T>: если автоматическое управление памятью с выделением памяти под большие обьекты справляется, а с выделением паняти под маленькие объекты не справляется, то это — полная ерунда ...
Полная ерунда это писать финалайзеры не соображая как это работает. Сама идея делать финалайзеры без неуправляемых ресурсов уже бред.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: WPF. Финализаторы не вызываются. Утечка памяти
T>>для меня лично такое- это откровенный баг
НС>Для тебя лично. Этому поведению уже 20 лет скоро.
T>>: если автоматическое управление памятью с выделением памяти под большие обьекты справляется, а с выделением паняти под маленькие объекты не справляется, то это — полная ерунда ...
НС>Полная ерунда это писать финалайзеры не соображая как это работает. Сама идея делать финалайзеры без неуправляемых ресурсов уже бред.
так я лично поэтому всегда Dispose и пользовался, краем уха слышал, что пользоваться finalizer не стоит...
так нафига finalizer воообще, если это банально не работает ?
Re[12]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, takTak, Вы писали:
НС>>Полная ерунда это писать финалайзеры не соображая как это работает. Сама идея делать финалайзеры без неуправляемых ресурсов уже бред.
T>так я лично поэтому всегда Dispose и пользовался, краем уха слышал, что пользоваться finalizer не стоит...
T>так нафига finalizer воообще, если это банально не работает ?
Здравствуйте, takTak, Вы писали:
S>>Мы говорим не о литературном русском языке, а о терминологии производителя. Деструкторов в CLR нет, т.к. деструктор подразумевает детерминистическую финализацию.
T>другие люди почему-то используют...
И они не правы, потому что слово "finalizer" для того и придумали, чтобы избежать слова "destructor".
Re: WPF. Финализаторы не вызываются. Утечка памяти
Мне кажется, что в оригинальном вопросе у вас в финализаторе освобождалось что-то другое. Зачем вам финализатор, если у вас нет неуправляемых ресурсов?
Re[8]: WPF. Финализаторы не вызываются. Утечка памяти
S>>>Мы говорим не о литературном русском языке, а о терминологии производителя. Деструкторов в CLR нет, т.к. деструктор подразумевает детерминистическую финализацию.
T>>другие люди почему-то используют...
bnk>И они не правы, потому что слово "finalizer" для того и придумали, чтобы избежать слова "destructor".
имхо никакого смысла плодить ненужные сущности нет: могли назвать недерминистическим дестрактором, тогда всем было бы всё понятно,
а чего стоит их "selectMany" в linq !? Поубибав бы(c)
Re[8]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, bnk, Вы писали:
bnk>И они не правы, потому что слово "finalizer" для того и придумали, чтобы избежать слова "destructor".
Ага, слово то дали другое, а синтаксис в C# скопирован с деструкторов.
Лучше бы как в Java пиши полностью: public override void Finalize(), тогда бы и меньше людей пихало бы в код финализаторов.
Здравствуйте, _NN_, Вы писали:
bnk>>И они не правы, потому что слово "finalizer" для того и придумали, чтобы избежать слова "destructor".
_NN>Ага, слово то дали другое, а синтаксис в C# скопирован с деструкторов. _NN>Лучше бы как в Java пиши полностью: public override void Finalize(), тогда бы и меньше людей пихало бы в код финализаторов.
Компромисс? Людям нужны знакомые вещи, пусть они немного и не такие какими кажутся
bnk>>>И они не правы, потому что слово "finalizer" для того и придумали, чтобы избежать слова "destructor".
_NN>>Ага, слово то дали другое, а синтаксис в C# скопирован с деструкторов. _NN>>Лучше бы как в Java пиши полностью: public override void Finalize(), тогда бы и меньше людей пихало бы в код финализаторов.
bnk>Компромисс? Людям нужны знакомые вещи, пусть они немного и не такие какими кажутся
ага, если что-то выглядит как утка, но то мяукуает, то хрюкает, то как это назвать ?
Re[2]: WPF. Финализаторы не вызываются. Утечка памяти
IB>>Создал минимальное воспроизводящее приложение.
С>Мне кажется, что в оригинальном вопросе у вас в финализаторе освобождалось что-то другое. Зачем вам финализатор, если у вас нет неуправляемых ресурсов?
Это модельное (не реальное приложение). Я его создал, что хоть как-то продемонстрировать проблему. В реальной приложении финализатор не пустой и нет бесконечных циклов в конструкторе, но утечка памяти такая же.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Re[6]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, Sinclair, Вы писали:
S>Мы говорим не о литературном русском языке, а о терминологии производителя. Деструкторов в CLR нет, т.к. деструктор подразумевает детерминистическую финализацию.
Ага. Повбивав би
Дать название из C++, а поведение совсем не такое как у деструкторов из C++:
Execution of the destructor for the instance may occur at any time after the instance becomes eligible for destruction.
When an instance is destructed, the destructors in that instance's inheritance chain are called, in order, from most derived to least derived.
A destructor may be executed on any thread.
Здравствуйте, Слава, Вы писали:
С>Мне кажется, что в оригинальном вопросе у вас в финализаторе освобождалось что-то другое. Зачем вам финализатор, если у вас нет неуправляемых ресурсов?
Не касаясь оригинальной задачи, пример использования финализаторов без неуправляемых ресурсов — контролировать утечки из пула.
Есть пул объектов (или их дорого инициализировать, или они большие и хочется переиспользовать память в LOH). Если при выдаче из пула подписывать объект на финализацию, а при возвращении в пул отписывать, а в финализатор вставить логирование, то вызов GC.Collect+WaitForPendingFinalizers покажет, а не утекло ли у нас что-то мимо пула.
Re[7]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, takTak, Вы писали:
T>не, даже без вложенного массива комбинация деконструктора и бесконечного цикла ведёт к outofmemory, T>хотя в finalizer программа регулярно заходит
Объекты создаются в цикле быстрее, чем поток финализации успевает обрабатывать их финализаторы, а GC не может убивать старые объекты, пока их финализаторы не отработали.
Re[8]: WPF. Финализаторы не вызываются. Утечка памяти
T>>не, даже без вложенного массива комбинация деконструктора и бесконечного цикла ведёт к outofmemory, T>>хотя в finalizer программа регулярно заходит
A>Объекты создаются в цикле быстрее, чем поток финализации успевает обрабатывать их финализаторы, а GC не может убивать старые объекты, пока их финализаторы не отработали.
так проблема для меня лично не столько в этом, а в том, что деструкторы больших по размеру объектов при всём этом без проблем работают : получается противоречивое поведение, когда программа ведёт себя различно в зависимости лишь от разницы в размере данных
Re[9]: WPF. Финализаторы не вызываются. Утечка памяти
Здравствуйте, takTak, Вы писали:
A>>Объекты создаются в цикле быстрее, чем поток финализации успевает обрабатывать их финализаторы, а GC не может убивать старые объекты, пока их финализаторы не отработали. T>так проблема для меня лично не столько в этом, а в том, что деструкторы больших по размеру объектов при всём этом без проблем работают
Повод измерить и сравнить скорость выделения 10кб в нулевом поколении и 100кб в large object heap. Если во втором случае заметно дольше, то финализаторы успевают отрабатывать.
T>>> получается противоречивое поведение, когда программа ведёт себя различно в зависимости лишь от разницы в размере данных
Это очевидная зависимость. Выдели на стеке буфер в мегабайт, а потом в десять мегабайт. Во втором случае будет StackOverflow. Ну, сам виноват, не уследил за размерами. И конечно большие объёмы данных обрабатывать дольше, чем маленькие ― скорость работы программы не может не отличаться.
A>>>Объекты создаются в цикле быстрее, чем поток финализации успевает обрабатывать их финализаторы, а GC не может убивать старые объекты, пока их финализаторы не отработали. T>>так проблема для меня лично не столько в этом, а в том, что деструкторы больших по размеру объектов при всём этом без проблем работают
A>Повод измерить и сравнить скорость выделения 10кб в нулевом поколении и 100кб в large object heap. Если во втором случае заметно дольше, то финализаторы успевают отрабатывать.
T>>>> получается противоречивое поведение, когда программа ведёт себя различно в зависимости лишь от разницы в размере данных
A>Это очевидная зависимость. Выдели на стеке буфер в мегабайт, а потом в десять мегабайт. Во втором случае будет StackOverflow. Ну, сам виноват, не уследил за размерами. И конечно большие объёмы данных обрабатывать дольше, чем маленькие ― скорость работы программы не может не отличаться.
речь ж не о скорости, а о том, что программа принципиально работает различно в зависисмости лишь от небольшой разницы в размере данных: 85к и меньше — не работает, 85к и больше(это даже не один мегабайт, карл!) — работает
: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/classes#destructors
