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.