Все привет. Волей случая пришлось разрабатывать собственный профилировщик для CLR и наткнулся на несколько не понятных моментов:
ICorProfilerCallback2::HandleCreated вызывается в том случае, если для некоторого объекта с initialObjectId создается дескриптор сборки мусора handleId, а событие ICorProfilerCallback2::HandleDestroyed - вызывается для дескриптора сборки мусора в том случае, если он был обработан, то есть связанный с ним объект был удален из памяти. Однако, в процессе профилирования я заметил, что не для всех дескрипторов созданных вызовом HandleCreated вызывается HandleDestroyed. Что может быть причиной и как это следует интерпретировать?ICorProfilerCallback::MovedReferences заметил следующее: предположим у нас есть два дапазон адресов A...B и C...D. В процессе обработки объекты из диапазона C...D переехали в E...F, а то что находилось в A...B было уничтожено. Однако, при следующей сборке мусора GC начинает активно перемещать блоки памяти в диапазоне A...B, хотя они уже были очищены ранее и созданий объектов в этом диапазоне адресов зафиксировано не было. Это какая то особенность работы GC или я что то не учитываю? Если что то не учитываю, то что? в какую сторону смотреть?GC нашлись в списке объектов, для которых был создан, но не выполнен дескриптор сборки мусора.Все эти 3 пункта не дают спокойно жить уже третий день. Кто сталкивался с подобным помогите плизз)
Сборка персонального компьютера от Artline: умный выбор для современных пользователей