HeapWalk() и managed heap. Может ли само приложение в какой-то точке своего кода запросить список своих объектов

@Владимир В · Регистрация: 06.05.2011

Author24 — интернет-сервис помощи студентам

Для неуправляемого кода существуют функции для получения информации об объектах, находящихся в куче. Например, HeapWalk() и все, что с ним связано. А можно ли их приспособить для перечисления объектов, созданных приложением операцией new в Managed Heap? Если нет, то как такое перечисление может быть сделано программно? Я имею в виду не утилиты вроде CLR Profiling API, которая бы следила за приложениями, запущенными в системе, а более простое дело - может ли само приложение в какой-то точке своего кода запросить список СВОИХ объектов, существующих в данный момент в Managed Heap?

Psilon · 30.11.2013, 15:33

Владимир В, Вроде нет. А зачем вам?

Добавлено через 6 минут
Хотя теоретически конечно же можно. У нас же есть GC, который определяет живые объекты.

@Владимир В · 30.11.2013, 15:50 **[ТС]**

Вот для чего : скажем, создаю в каком-нибудь методе-обработчике нажатия кнопки объект-форму-диалог с помощью new : MyForm dlg = new MyForm(); dlg.ShowDialog(). Пусть диалог отработал, закрылся, из из метода, где диалог создавался, мы вышли. Сборщик мусора рано или поздно должен этот объект удалить (или нет?). А вот если в форме MyForm был создан Forms.Timer таймер и включен, и при закрытии диалога мы его не остановили, то тогда объект диалога не будет удален даже если снова войти в обработчик и создать новый диалог MyForm dlg = new MyForm().
Так и будут копиться объекты диалога при каждом входе в диалог и плодиться таймеры. А если таймеров нет - то тогда, наверное, объекты диалога плодиться не будут (?). Но это все мои предположения - хотелось бы (в учебных целях) убедиться программно, и для этого иметь метод, получающий в желаемый момент список объектов в Manage Heap. Безусловно, я и хотел воспользоваться GC, который определяет живые объекты, но вроде не нашел у него методов, возвращающих нужную информацию. Не знаю, как это сделать с помощью GC

Psilon · 30.11.2013, 16:31

Владимир В, удаляется любой объект, на который нет ссылок. Так что ничего не копится. Ни таймеры, ни диалоги. Если только не забывать Dispose вызывать. Покажите код, который у вас вопросы вызывает.

Добавлено через 39 минут
Владимир В, и кстати, судя по всему, это невозможно (Я на СО спросил), ответ:

No, the GC heap doesn't use any winapi functions to implement the heap, it is implemented from scratch. The only operating system call is VirtualAlloc() to allocate the address space for a heap segment. Querying that with VirtualQuery() is not useful, that would only show you the big chunks without being able to observe the internal structure.

The CLR does expose low-level debugging probes into the GC heap through the DAC, supported by mscordacwks.dll. This is used most notably by the SOS debugger extension. But an essential requirement is to avoid the Heisenberg effect, it cannot be used inside the process because that would alter what you observe. It must only be used by another process, the debugger, and only when the execution of the process is completely frozen so internal data structures are stable. Which puts the kibosh on any idea to have a program itself use the feature.

If a "self-check" is what you are after then you don't have to help, that's already done frequently. It happens every time the garbage collector runs. A self-check failure is reported with ExecutionEngineException.

@Владимир В · 30.11.2013, 16:34 **[ТС]**

Правильно, если вызывать Dispose. Но я хотел убедиться, что если не вызывать, то сборщик мусора через какое-то время все равно должен объект убрать. Сделал пример, в котором диалог вызывается из формы, и считал, что после выхода из обработчика, где диалог создавался, ссылка на него приложению уже не нужна. В крайнем случае она
станет ненужной после повторного вызова обработчика, в котором создается и вызывается диалог. Но в самой форме диалога у меня был запущен таймер, который я случайно не остановил - и в таком случае сборщик мусора не будет удалять такие диалоги, и они (уже невидимые) будут копиться и все их таймеры работать. Это я и заметил визуально. Для этого не нужно анализировать Heap, работающие таймеры сами это покажут. Если таймер останавливать при закрытии диалога, то даже без Dispose сборщик мусора должен объект убрать.

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

Psilon · 30.11.2013, 16:35

Сообщение от Владимир В

Но вопрос не в этом. Как с помощью GC запросить информацию о живых объектах приложения?

никак. Выше же ответ.

@Владимир В 1 / 1 / 1 Регистрация: 06.05.2011 Сообщений: 110
		1
	HeapWalk() и managed heap. Может ли само приложение в какой-то точке своего кода запросить список своих объектов 30.11.2013, 15:13. Показов 975. Ответов 5 Метки нет (Все метки) Для неуправляемого кода существуют функции для получения информации об объектах, находящихся в куче. Например, HeapWalk() и все, что с ним связано. А можно ли их приспособить для перечисления объектов, созданных приложением операцией new в Managed Heap? Если нет, то как такое перечисление может быть сделано программно? Я имею в виду не утилиты вроде CLR Profiling API, которая бы следила за приложениями, запущенными в системе, а более простое дело - может ли само приложение в какой-то точке своего кода запросить список СВОИХ объектов, существующих в данный момент в Managed Heap? 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	30.11.2013, 15:33	2
	Владимир В, Вроде нет. А зачем вам? Добавлено через 6 минут Хотя теоретически конечно же можно. У нас же есть GC, который определяет живые объекты. 0

@Владимир В 1 / 1 / 1 Регистрация: 06.05.2011 Сообщений: 110
	30.11.2013, 15:50 [ТС]	3
	Вот для чего : скажем, создаю в каком-нибудь методе-обработчике нажатия кнопки объект-форму-диалог с помощью new : MyForm dlg = new MyForm(); dlg.ShowDialog(). Пусть диалог отработал, закрылся, из из метода, где диалог создавался, мы вышли. Сборщик мусора рано или поздно должен этот объект удалить (или нет?). А вот если в форме MyForm был создан Forms.Timer таймер и включен, и при закрытии диалога мы его не остановили, то тогда объект диалога не будет удален даже если снова войти в обработчик и создать новый диалог MyForm dlg = new MyForm(). Так и будут копиться объекты диалога при каждом входе в диалог и плодиться таймеры. А если таймеров нет - то тогда, наверное, объекты диалога плодиться не будут (?). Но это все мои предположения - хотелось бы (в учебных целях) убедиться программно, и для этого иметь метод, получающий в желаемый момент список объектов в Manage Heap. Безусловно, я и хотел воспользоваться GC, который определяет живые объекты, но вроде не нашел у него методов, возвращающих нужную информацию. Не знаю, как это сделать с помощью GC 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	30.11.2013, 16:31	4
	Владимир В, удаляется любой объект, на который нет ссылок. Так что ничего не копится. Ни таймеры, ни диалоги. Если только не забывать Dispose вызывать. Покажите код, который у вас вопросы вызывает. Добавлено через 39 минут Владимир В, и кстати, судя по всему, это невозможно (Я на СО спросил), ответ: No, the GC heap doesn't use any winapi functions to implement the heap, it is implemented from scratch. The only operating system call is VirtualAlloc() to allocate the address space for a heap segment. Querying that with VirtualQuery() is not useful, that would only show you the big chunks without being able to observe the internal structure. The CLR does expose low-level debugging probes into the GC heap through the DAC, supported by mscordacwks.dll. This is used most notably by the SOS debugger extension. But an essential requirement is to avoid the Heisenberg effect, it cannot be used inside the process because that would alter what you observe. It must only be used by another process, the debugger, and only when the execution of the process is completely frozen so internal data structures are stable. Which puts the kibosh on any idea to have a program itself use the feature. If a "self-check" is what you are after then you don't have to help, that's already done frequently. It happens every time the garbage collector runs. A self-check failure is reported with ExecutionEngineException. 0

@Владимир В 1 / 1 / 1 Регистрация: 06.05.2011 Сообщений: 110
	30.11.2013, 16:34 [ТС]	5
	Правильно, если вызывать Dispose. Но я хотел убедиться, что если не вызывать, то сборщик мусора через какое-то время все равно должен объект убрать. Сделал пример, в котором диалог вызывается из формы, и считал, что после выхода из обработчика, где диалог создавался, ссылка на него приложению уже не нужна. В крайнем случае она станет ненужной после повторного вызова обработчика, в котором создается и вызывается диалог. Но в самой форме диалога у меня был запущен таймер, который я случайно не остановил - и в таком случае сборщик мусора не будет удалять такие диалоги, и они (уже невидимые) будут копиться и все их таймеры работать. Это я и заметил визуально. Для этого не нужно анализировать Heap, работающие таймеры сами это покажут. Если таймер останавливать при закрытии диалога, то даже без Dispose сборщик мусора должен объект убрать. Но вопрос не в этом. Как с помощью GC запросить информацию о живых объектах приложения? Чтобы, к примеру, по этому списку увидеть, что в одном случае диалоги копятся, в другом нет, если делать Dispose и не делать - и т.д. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	30.11.2013, 16:35	6
	Сообщение от Владимир В Но вопрос не в этом. Как с помощью GC запросить информацию о живых объектах приложения? никак. Выше же ответ. 0