-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix a few profiler related issues associated with frozen objects #79563
Conversation
Tagging subscribers to this area: @tommcdon Issue DetailsThis change fixes a few profiler-related issues associated with frozen objects.
Reset the pinned queue only once This was an existing bug that is unrelated to frozen objects (for reason I don't understand it only got exposed recently). In There is only one pinned queue shared across all generations. Therefore we should not reset the pinned queue for every generation. Publish frozen objects Some profilers track object instances. If we don't report an object as allocated, they won't be tracking it, and they might be surprised if later on the object is reported as root. Before the change, frozen objects are not reported as allocated. After the change, frozen objects allocated through Report the frozen segments as survived Some profilers might assume that objects previously allocated not falling in that survived range are being collected. Before the change, frozen segments are not reported, and therefore the profiler might assume frozen objects are collected, while they are not, and then got surprised that they got reported as root. After the change, the frozen segments are reported as survived, to do that, the Set frozen segment As we report the regions to the profiler, we will read the @dotnet/gc
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM from the profiler side, I am not a GC expert though :)
@Maoni0 and I had a discussion on this and we believe reporting the frozen segments as a plug is inappropriate. We need a different fix for that part. |
b2bd91f
to
49971fd
Compare
49971fd
to
38c0e6e
Compare
This change fixes a few profiler-related issues associated with frozen objects.
3. Report the frozen segments as survivedgen_num
Reset the pinned queue only once
This was an existing bug that is unrelated to frozen objects (for reason I don't understand it only got exposed recently).
In
walk_relocation
, we walk the generations (from old to young), the associated bricks (in region list order), and the associated plug trees (using an in-order traversal). During the walk, we dequeue the pinned plugs from the pinned plug queue.There is only one pinned queue shared across all generations. Therefore we should not reset the pinned queue for every generation.
Publish frozen objects
Some profilers track object instances. If we don't report an object as allocated, they won't be tracking it, and they might be surprised if later on the object is reported as root.
Before the change, frozen objects are not reported as allocated.
After the change, frozen objects allocated through
FrozenObjectHeapManager::TryAllocate
are now reported to the profiler throughPublishObjectAndNotify
, and therefore they will be available throughICorProfiler::ObjectAllocated
callback.Report the frozen segments as survivedSome profilers might assume that objects previously allocated not falling in that survived range are being collected.Before the change, frozen segments are not reported, and therefore the profiler might assume frozen objects are collected, while they are not, and then got surprised that they got reported as root.After the change, the frozen segments are reported as survived, to do that, thewalk_relocation_sip
method is renamed towalk_relocation_special_segments
to also handle the special case for frozen segments.Set frozen segment
gen_num
As we report the regions to the profiler, we will read the
gen_num
of the heap segment. The current code didn't set that value, so we might be reading random numbers in the profiler. That's not good. As an implementation detail, we thread the frozen segment into gen2, so we might as well set thegen_num
to 2 there.@dotnet/gc