Add option to instrument using 64-bit counts

[jakobbotsch]

Add COMPlus_JitCollect64BitCounts which makes the JIT instrument using
64-bit counts instead of 32-bit counts.

I also changed the printing of relocs to include their values when
diffable disassembly is off.

[AndyAyersMS]

I confess I have a slight preference for the old names. The new type could be BasicBlockLongCount for instance. But I can get used to these names.

I wonder if we should finish wiring this up in case we're seeing count saturation in our training scenarios (I have not seen evidence of this, but haven't really looked). Aside from the missing count consumption parts in the jit there is a counter for type histograms that will overflow if block counts are overflowing.

cc @davidwrighton

[jakobbotsch]

No worries, I'll change the names back and use Long for the new one instead.

[jakobbotsch]

I wonder if we should finish wiring this up in case we're seeing count saturation in our training scenarios (I have not seen evidence of this, but haven't really looked). Aside from the missing count consumption parts in the jit there is a counter for type histograms that will overflow if block counts are overflowing.

I can certainly spend some more time to get the consumption part working as well. However, given that we only see overflows with COMPlus_TC_CallCounting=0, it seems unlikely that overflows happen in practice. I suppose it could happen in the real world if a function is stuck in tier 0, however. In that case I'm not sure if you would want to enable 64-bit counts over OSR, though.

[davidwrighton]

@jakobbotsch our training scenarios don't quite set COMPLUS_TC_CallCounting to 0, but they do something very similar to collect instrumentation data. So it very well might be interesting to turn that on for training data collection

[davidwrighton]

All of this reminds me that I desperately need to build a set of tests which actually exercise the entire static pgo pipeline within our testbed, as I keep missing steps in validation.

[jakobbotsch]

Makes sense, I'll work on threading the 64-bit counts through more thoroughly then.

[jakobbotsch]

I have done this so far, but shouldn't we ideally also be taking other PGO data into account here? @AndyAyersMS

[AndyAyersMS]

Perhaps? I left these out on purpose, though we might reconsider.

The class profile data ends up interspersed with the count data, so the hash below will typically incorporate those values; the schema records themselves don't contain that much interesting content.

[jakobbotsch]

@davidwrighton can you advise on what needs to be done with crossgen/crossgen2? Do both need to be updated? The JIT side of this change should be done now.

[jakobbotsch]

@AndyAyersMS this should be good for a review, I guess the runtime parts can come in a separate PR.

[AndyAyersMS]

LGTM.

Dynamic PGO should be able to consume these counts, right? In that case the runtime doesn't do much with the data....

[AndyAyersMS]

Perhaps? I left these out on purpose, though we might reconsider.

The class profile data ends up interspersed with the count data, so the hash below will typically incorporate those values; the schema records themselves don't contain that much interesting content.

[jakobbotsch]

Dynamic PGO should be able to consume these counts, right? In that case the runtime doesn't do much with the data....

Right, I meant crossgen/crossgen2. I checked and indeed with COMPlus_TieredPGO=1 and COMPlus_JitCollect64BitCounts=1 the counts are roundtripped correctly.

[jakobbotsch]

The failure seems unrelated (seen before in https://dev.azure.com/dnceng/public/_build/results?buildId=1114013&view=results and https://dev.azure.com/dnceng/public/_build/results?buildId=1113899&view=results).