Fix failing test on NativeAOT

[noahfalk]

Fixes #109828
This test hadn't been updated to account for NativeAOT's lack of type names in the new randomized sampling allocation events.

[noahfalk]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[noahfalk]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[noahfalk]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[noahfalk]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[noahfalk]

@jkotas @MichalStrehovsky - I think this resolves the failure in the allocation sampling test though it appears the outer loop runs still have some other failures in the Numerics tests.

[MichalStrehovsky]

@jkotas @MichalStrehovsky - I think this resolves the failure in the allocation sampling test though it appears the outer loop runs still have some other failures in the Numerics tests.

That one was fixed in #109842. We could rebase and recheck, but I think this is good to merge as-is! Thanks!

Btw, we are able to compute type names of everything on the GC heap (since we keep it around for object.GetType to work). If it's possible to call into managed code at the spot where this is needed (we can only compute the names in managed code), it should be fixable.

[tommcdon]

Thanks!

[noahfalk]

Btw, we are able to compute type names of everything on the GC heap (since we keep it around for object.GetType to work). If it's possible to call into managed code at the spot where this is needed (we can only compute the names in managed code), it should be fixable.

Ah thats good to know. I had been under the impression the names were strippable like other metadata and couldn't be assured. The place where we need the name is here: https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/Runtime/GCHelpers.cpp#L485

The callstack would look like:

FireAllocationSampled
GcAllocInternal
RhAllocateXYZ
ManagedCode

I assume there isn't anything preventing a native->managed call at that point but it would be a little odd if managed code did any allocations which could lead to recursion. Not knowing what is involved just yet, do you think we could keep that call allocation-free?

[jkotas]

I assume there isn't anything preventing a native->managed call at that point but it would be a little odd if managed code did any allocations which could lead to recursion.

Right, it would not be pretty to make this work.

Sending the type name as part of each sample can result in a lot of redundant information being transferred. Would it be better to send the type id to type name mapping in separate events, once for each type id? It would work better for native AOT as well.

[noahfalk]

Sending the type name as part of each sample can result in a lot of redundant information being transferred. Would it be better to send the type id to type name mapping in separate events, once for each type id? It would work better for native AOT as well.

It is possible to create separate events that do id->name mapping, but that bring some alternate complexity to track which mappings need to be sent and dealing with potential dropped events carrying the mapping data. Historically all the AllocationTick events carried the name information inline and I'm not aware of any complaints about data size. The plan for NativeAOT is that TypeId can be looked up in a PDB. Assuming the profiler cares about stack traces where the allocations are occurring it will need to do PDB lookups for code IPs already. If we get some feedback from profiler vendors that ID->name mapping events would be helpful nothing precludes us from adding it (as well as offering a name-free variant of the AllocationSampled event) but I'm going to hold off on increasing the feature scope for now.

[MichalStrehovsky]

The plan for NativeAOT is that TypeId can be looked up in a PDB. Assuming the profiler cares about stack traces where the allocations are occurring it will need to do PDB lookups for code IPs already.

The stack traces are a similar story - we do have that information (unless the user specified StackTraceSupport=false property), but it's only computable in managed code.

The information that we have in metadata both for types and method bodies is more structured than in the PDB - the PDB only has mangled names that are not particularly reversible. It works, but it won't produce nice identifier names. But it's better than nothing, and good enough 98% of time.

I guess none of this is something that we would need to address now, just something to keep in mind should we have a need for this.