JitStressRange usability issues

[AndyAyersMS]

JitStressRange is useful for narrowing down stress failures to a particular method. However this process is hampered by some odd behaviors. Here are some suggestions for usability improvements:

1. The hash used by JitStressRange is the "old" hash, different than the one computed by compMethodHash. This makes it hard to use the results of COMPlus_DumpJittedMethods or similar to try and identify hash ranges for stress isolation.
2. The stress ranges are specified in decimal but the hashes are dumped in hex.
3. The stress ranges tend to be large numbers and are easy to mis-type by hand; might be good if they are optionally echoed back out once parsed.
4. It would be nice to see some indication that stress was applied in the simpler jit diagnostic output streams (like DumpJittedMethods), so one can be sure stress range isolation is working as expected.

[AndyAyersMS]

FYI @dotnet/jit-contrib

Similar issues seen for JitNoInlineRange (though this is probably not often used).

[AndyAyersMS]

Some other challenges with stress mode isolation (with an eye towards one day automating the process, ala git bisect):

If a method is stressed it can make different inlining decisions then when it is not stressed. In particular if we see a failure with an unrestricted JitStress, where some method set M was jitted, as we exclude methods from stress we may see new methods jitted that are not in M or we may see methods in M no longer get jitted on their own.

So an automatable isolation process needs to hold inlining constant. This is possible via inline replay, though if inline stress is the cause of the problem then we may end up in a mode where no method is stressed (but all are replaying stress mode inlines) and we still see failures.

Another similar issue is that if a stress mode is applied to an inlinee during importation (or any time up until inlining), that decision, it keys off the inlinee name and hash, and those are not as readily discoverable / isolatable as the root method. There don't seem to be many of these early stress points, at least not many direct stress checks in the importer proper (there are likely some indirect ones). It might make sense for all stress decisions to defer to the root compiler instance.

[CarolEidt]

It might make sense for all stress decisions to defer to the root compiler instance.

That makes sense to me.

[AndyAyersMS]

Should be largely fixed by #2313.