ICorProfilerCallback GC related behavior changed in CoreCLR 8.0? #106543
Labels
area-Diagnostics-coreclr
question
Answer questions and provide assistance, not an issue with source code or documentation.
Milestone
During investigation issue in our managed profiler with CoreCLR 8.0, I found, that start from CoreCLR 8.0 we have different behavior for
ICorProfilerCallback::ObjectReferences
,ICorProfilerCallback::RootReferences
andICorProfilerCallback2::SurvivingReferences
.Tested on Linux amd64/arm64/arm32.
I made simple profiler based on https://github.com/dotnet/samples/tree/main/core/profiling
that log all data we need for testing, here is sources: profiling.zip
and simple application:
In case CoreCLR 7.0 or prevous versions, we have all
ICorProfilerCallback::ObjectReferences
andICorProfilerCallback::RootReferences
refs inside surviving ranges provided byICorProfilerCallback2::SurvivingReferences
.In this case my simple profiler provide log like this:
but in case CoreCLR 8.0 and CoreCLR 9.0 preview, some objects or root references could be out of surviving references ranges:
I am also worry, why this out of surviving ranges references have so strange addresses (surviving refs are close to 14023xxxxxxxxxx but out of surviving range refs have 14051xxxxxxxxxx, looks like some another "generation", but
ICorProfilerCallback2::GarbageCollectionStarted
still provide only 5 as usual).Could you please share more info what were changed in CoreCLR 8.0 GC? Is this proper ICorProfilerCallback behaviour for CoreCLR 8.0?
Looks like some new memory storage was added (like LOH or POH), but
ICorProfilerCallback2::GarbageCollectionStarted
andICorProfilerCallback2::SurvivingReferences
don't care about it now.CC @gbalykov
The text was updated successfully, but these errors were encountered: