Diagnostic support for frozen string literals

[jkotas]

Anywhere that we enumerate contents of the managed heap or sizes of the heap we need to include the Frozen Object Heap. We've got a few possible conceptual designs: a. Treat the Frozen Object Heap as a private implementation detail of some other part of the GC heap, for example considering it a subset of SOH gen2, or a subset of the pinned object heap. b. Disclose the Frozen Object Heap as a new top level category within the GC. We would now have 4 GC regions - SOH, POH, LOH, and Frozen Object Heap (FOH). c. Disclose the Frozen Object Heap as a new memory region that holds managed objects, but is distinct from the GC entirely.

If we choose (a) we need to ensure all our accounting mechanisms treat Frozen Object Heap consistently. This includes everything in https://github.com/dotnet/diagnostics/issues/1408 and the new GC.GetMemoryInfo() APIs that were added more recently.

If we choose options (b) or (c) in addition to consistent accounting mechanisms we also need new top-level categories and we need to raise awareness with 3rd party tools so that they expose the new information. Again see https://github.com/dotnet/diagnostics/issues/1408 as a prior example.

Because allocation on the Frozen Object Heap doesn't go through some of the normal accounting mechanisms, here are things we need to handle no matter what:

• Call allocate object callback when a frozen string literal is allocated
• Report frozen segments from GetGenerationBounds profiler interface
• Classify object generation in GetObjectGeneration
• Figure out what the allocation sampling story is for these objects with AllocationTick.

Context: https://github.com/dotnet/runtime/pull/49576#issuecomment-1250092961

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[msftbot[bot]]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch See info in area-owners.md if you want to be subscribed.

Issue Details

---

• Call allocate object callback when a frozen string literal is allocated
• Report frozen segments from GetGenerationBounds profiler interface

Context: https://github.com/dotnet/runtime/pull/49576#issuecomment-1250092961

Author:	jkotas
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[noahfalk]

@jkotas @Maoni0 - I understand that you both talked offline and agreed on this new path that Frozen Object Heap will not be included conceptually anywhere that we have named things as 'GC'. I updated the text above to capture that and updated impact on diagnostics accordingly. If you have any issues I want to get those resolved.

[jkotas]

GCSampledObjectAllocation masks referencing allocation (COR_PRF_MONITOR_OBJECT_ALLOCATED, COR_PRF_ENABLE_OBJECT_ALLOCATED) should apply to all heaps.

How is this expected to work for file-backed non-GC heap segments? I think it would be more future proof to not produce fine grained allocation events for non-GC heap segments and treat these allocations as other non-GC managed memory allocations where we do not provide fine-grained events eithers.