Feature Request: During a profiler walk of the GC heap reference graph, distinguish references that aren't backed by metadata fields

[noahfalk]

This is a request from https://github.com/dotnet/coreclr/issues/16274#issuecomment-381434436

Well, could you please add the markers for virtual references in ICorProfilerCallback? I need to know that the reference to LoaderAllocator is virtual. I have the list of classes where the reference to LoaderAllocator isn't virtual. How can I understand after CLR/CoreCLR update that I have to add the new type in the list?

FWIW, I don't think that the information needs to be directly provided as an argument of the ICorProfilerCallback::ObjectReferences API (or a numbered extension of the API), but there would need to be some not too complicated and reasonably performant mechanism for a profiler to learn the information. This is part of a broader ask that the profiler wants to understand not just what references an object has, but specifically how those references correlate to its fields, nested fields, array elements, etc. Right now profilers are using heuristics because the APIs to access types and type layouts have difficulties in some cases. The implicit references created by collectible assemblies add an additional layer of complexity.

[RussKeldorph]

@noahfalk 2.2? Future?

[noahfalk]

Based on further discussion in #9685 , a suggested implementation here would be to create a new ObjectReferences2, which supplies both the list of references and a list of offsets. The offset is the position within the object where the reference was read from, or a -1 for references that were implicitly defined/calculated.

Likely we wouldn't want to emit both ObjectReferences and ObjectReferences2, so we'd need some way for the profiler to pick. Perhaps something in SetEventMask?

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.