Fix VS4Mac crash report and core dump generation perf problems

[mikem8361]

Customer Impact

This is a VS4Mac show stopper. The performance (4 min or so) of taking a core dump when VS4Mac crashes or hangs is unacceptable.

Details

Backport of #60205

Move createdump's DAC enumerate memory region phase after the crash report json file generation is finished. This is so the crash report json is written and available before the core dump which VS4Mac has requested.

Since on both Linux and MacOS all the RW regions have been already added by createdump itself for heap dumps, then the sometimes slow (4 minutes for VS4Mac) heap enum memory region is changed to the faster normal one. It adds necessary DAC globals, etc. without the costly assembly, module, class, type runtime data structure enumeration.

This fast heap dumps is opt'ed in with COMPlus_DbgEnableFastHeapDumps=1 env var to mitigate the risk of something missing from these dumps. With this flag, dump generation is in the seconds now. VS4Mac will set this env var.

Testing

Tested creating a crash report/core dump against VS4Mac process manually. Ran all the SOS tests on MacOS and Linux against this change. The VS4Mac team has signed off on this change.

Risk

Low since there is an opt-in env var that enables the most risk part.

[ghost]

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

Issue Details

---

Customer Impact

This is a VS4Mac show stopper. The performance (4 min or so) of taking a core dump when VS4Mac crashes or hangs is unacceptable.

Details

Backport of #60205

Refactor the DAC enumerate memory region phase out of gather crash info

This is so the crash report json is written and available before the core dump which for VS4Mac currently takes 4 minutes.

Since on both Linux and MacOS all the RW regions have been already added by createdump itself for heap dumps, then the sometimes slow (4 minutes for VS4Mac) heap enum memory region is changed to the faster normal one. It adds necessary DAC globals, etc. without the costly assembly, module, class, type runtime data structure enumeration.

This fast heap dumps is opt'ed in with COMPlus_DbgEnableFastHeapDumps=1 env var to mitigate the risk of something missing from these dumps.

Testing

Tested creating a crash report/core dump against VS4Mac process. Ran all the SOS tests on MacOS and Linux against this change.

Risk

Low since there is an opt-in env var that enables the most risk part.

Author:	mikem8361
Assignees:	mikem8361
Labels:	Servicing-consider, area-Diagnostics-coreclr
Milestone:	6.0.0

[mikem8361]

@cshung could you make sure there isn't anything needed for this 6.0 backport for the GC change you made in PR #60205. It doesn't look like 6.0 needed your change.

[cshung]

@cshung could you make sure there isn't anything needed for this 6.0 backport for the GC change you made in PR #60205. It doesn't look like 6.0 needed your change.

I just checked and I confirm my change in PR #60205 is unnecessary for 6.0

[jeffschwMSFT]

Approved. Please get a few code reviews and then we can take for consideration in .NET 6. Given we are really close to GA, please get a few more code reviewers.

[sgmunn]

I was able to test this with vsmac by, in addition to signing, disabling SIP debug restrictions. The dump was created within, maybe, 10seconds and our crash reporter found the files and processed them. @kdubau and I quickly looked at the dumps and they appear to be what we expect. We believe we can sign off on this for vsmac.