Make sure ServerGCHeapDetails is up to date

[cshung]

Fixes#54368

In order to make sure the debugger does the correct thing for both workstation and server GC, we need to make sure when it load fields, it loads the same set of fields, and they load the correct value.

These are all fields are defined on the gc_heap class, and they were defined as such:

PER_HEAP card_table was defined unconditionally.
PER_HEAP mark_array was defined under BACKGROUND_GC.
PER_HEAP next_sweep_obj was defined under BACKGROUND_GC.
PER_HEAP background_saved_lowest_address was defined under BACKGROUND_GC.
PER_HEAP background_saved_highest_address was defined under BACKGROUND_GC.
PER_HEAP saved_sweep_ephemeral_seg was defined under !USE_REGIONS, BACKGROUND_GC.
PER_HEAP saved_sweep_ephemeral_start was defined under !USE_REGIONS, BACKGROUND_GC.

PER_HEAP means it is static for work station and instance for server.

In .NET 6, we planned to use clrgc.dll for USE_REGIONS and coreclr.dll for !USE_REGIONS. Therefore we will have a different layout of the gc_heap class depending on whether or not we use the standalone GC. To accommodate this situation, the loading of the dac_gc_heap class is now metadata-driven. Instead of assuming the layout of dac_gc_heap matches gc_heap, the GC will export an array of field offsets, and the DAC will load the fields according to the offsets.

@dotnet/dotnet-diag

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #54368

@dotnet/dotnet-diag

Author:	cshung
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[Maoni0]

@noahfalk PTAL.

@cshung I see what you meant by having to write the same class 3 times but I have no better idea how you could get around that. maybe @noahfalk knows a way?

[noahfalk]

@cshung I see what you meant by having to write the same class 3 times but I have no better idea how you could get around that. maybe @noahfalk knows a way?

There is a macro technique we use elsewhere in runtime code that may be helpful here. In one file we define a bunch of data as the arguments to macros and then we include that file in different places with different definitions of what the macros mean. For example the data might be:

//gc_typefields.hDEFINE_FIELD(gc_heap, uint8_t*, uint8_t*, alloc_allocated)
DEFINE_FIELD_DPTR(gc_heap, heap_segment, dac_heap_segment, ephemeral_heap_segment)
...
#ifdef BACKGROUND_GC_FIELDS
DEFINE_FIELD(gc_heap, uint32_t*, uint32_t*, mark_array)
...
#elseDEFINE_MISSING_FIELD(gc_heap, uint32_t*, uint32_t*, mark_array)
...
#endif

Then DAC might include like this:

int i = 0;
#defineBACKGROUND_GC_FIELDS
#defineDEFINE_FIELD(typename, runtimeFieldType, dacFieldType, fieldName) LOAD(fieldName, i, dacFieldType); i++;
#defineDEFINE_FIELD_DPTR(typename, runtimeFieldType, dacFieldType, fieldName) LOAD_DPTR(fieldName, i, dacFieldType); i++;
#include"gc_typefields.h"

And runtime layout generator might include like this:

#ifdef BACKGROUND_GC
#defineBACKGROUND_GC_FIELDS
#endif
#defineDEFINE_FIELD(typename, runtimeFieldType, dacFieldType, fieldName) offsetof(runtimeType, runtimeFieldType),
#defineDEFINE_FIELD_DPTR(typename, runtimeFieldType, dacFieldType, fieldName) offsetof(runtimeType, runtimeFieldType),
#defineDEFINE_MISSING_FIELD(typename, runtimeType, runtimeFieldType, dacFieldType, fieldName) -1,
staticint gc_heap_field_offsets[] = {
#include"gc_typefields.h"
};

What I wrote above probably needs some adjustment to make it work, but hopefully it conveys the idea.
A complete working example of this pattern in the runtime is corelib.h and an inclusion in binder.h. Like most macro things it can be a little harder read/debug in exchange for letting you consolidate different codegen from a single common definition of the type information. Its entirely your call whether you find it appealing or you prefer to manually keep the different code pieces in sync.

[noahfalk]

Modulo the few commented bits it looked good to me : )

[noahfalk]

The more interesting part is the generation_table, we will only fill 4 generations, and there is nothing we can do about that since DacpGcHeapDetails cannot be changed.

A change there would require changing SOS, which is certainly doable, but entirely reasonable to be out-of-scope for this PR. @davmason - do you know if only supporting 4 generations in the DacpGcHeapDetails is preventing SOS from properly supporting pinned object heap or it turned out not to be relevant?

[davmason]

A change there would require changing SOS, which is certainly doable, but entirely reasonable to be out-of-scope for this PR. @davmason - do you know if only supporting 4 generations in the DacpGcHeapDetails is preventing SOS from properly supporting pinned object heap or it turned out not to be relevant?

I ended up adding new APIs to be able to support POH: #37853