Fix the multicore performance of mapping from an instruction pointer to a MethodDesc

[davidwrighton]

Mapping from an instruction pointer to a MethodDesc is a critical component of the runtime used in many places, notably diagnostics, slow path delegate creation, and stackwalking.

This change provides a dramatic improvement in the performance of that logic through several techniques.

1. The mapping from IP to range of interesting memory is done via a tree structure resembling that of a page table. The result of this is that in addition to reducing the locking logic, the cost of looking up in the presence of many different loaded assemblies will be reduced to a nearly constant time.
2. That tree structure is configured so that when accessing memory which will never be freed in the lifetime of the process, the memory can be accessed without taking any locks whatsoever.
3. The code map is enhanced to include not only the code generated by the JIT/R2R code, but also to include the fixup and stub precode stubs.
4. In addition, performance improvement was done to improve the performance of slow path delegate creation in particular, by reordering which checks are done, and by writing a simplified signature parse routine for computing the number of arguments to a function.

Performance of this was tested in both the EH stackwalking scenario as well as the delegate slow path creation scenario, but the delegate logic is what will be most visible when this is checked in. (See PR #79471 for details of the additional changes necessary to take advantage of this work when doing EH) (#8393 describes the potential product impact of just improving the delegate slow path creation code)

For the delegate creation scenario the perf impact was measured to be quite substantial. These numbers are in ms to create a constant number of delegates on each thread used. Smaller is better. The test was run on a 6 core machine.

Threads	Without fix	With this PR
1	840	313
2	1977	316
3	3290	325
4	4259	344
5	5140	351
6	5872	374
7	6463	442
8	7046	499
9	7648	547
10	8241	627
11	8851	749
12	9595	773

Fixes #8393
Replaces the controversial logic in PR #68607

[EgorBo]

Nice! Does it make ExecutionManager::IsReadyToRun(PCODE) cheap? (I wanted to rely on it being cheap in some of my experiments)

[davidwrighton]

@EgorBo, yes, I do expect that this will make IsReadyToRun very cheap. (Probably 5-6 memory loads from separate pages plus some math, so repeated calls should be extremely cheap, and random calls will be somewhat expensive, but not bad.) The implementation as written has a risk of entering a lock under some circumstances, but after sleeping on it, I think we could get rid of that for the IsReadyToRun logic, and be assured that IsReadyToRun is cheap. What do you think you can optimize?

[EgorBo]

What do you think you can optimize?

I'd like to sort of de-prioritize R2R'd code for tier1 promotion in favor of non R2R'd one.

[davidwrighton]

@EgorBo, fyi, ExecutionManager::IsReadyToRun is slower than ExecutionManager::FindReadyToRunModule. Also, I've found there may be a slight bug in the current implementation of the locking strategy for those 2 methods, so I'm addressing that as well. ExecutionManager::IsReadyToRun validates that the pointer is actually a pointer to real compiled code, and return false for thunks and other things from a ReadyToRun image. Its possible we may want to change the definition of IsReadyToRun to make more sense.

[jkotas]

LGTM modulo feedback. Nice work!