Consider dynamically increasing number of fast generic dictionary slots

[jkotas]

Generic methods are given 4 special dictionary slots that can be used for fast lookup. There is similar limit for generic types.

These limits came from fragile NGen. With R2R, there should be nothing fundamental preventing us from making the number of dictionary slots for generic methods dynamic, grow the number of fast slots as necessary to give each generic method the exact number of slots it needs to run efficiently.

More context: https://github.com/dotnet/coreclr/issues/22400#issuecomment-462184185:

[sergiy-k]

@fadimounir, could you please estimate whether this is something we can improve in 3.0?

[fadimounir]

@sergiy-k Shouldn't be too much work to implement. I think we'll need to fix the allocation logic in DictionaryLayout::FindTokenWorker a bit to resize the existing dictionary (allocate larger dictionary, copy old entries, and update the MethodDesc with the pointer to the new dictionary). It's easy to get this into 3.0.

@jkotas Out of curiosity, why did we have that 4 limit in the first place, and reverted to using the slow helper when we ran out of slots? Was it a memory usage concern in the past? I'm trying to understand what changed compared to the past to make it ok to dynamically size these slots today.

[jkotas]

need to fix the allocation logic in DictionaryLayout::FindTokenWorker a bit to resize the existing dictionary

You will need to resize the dictionary on all types. It would need to take advantage of the type dependency tracking that @davidwrighton and @kouvel have been working on. I am not sure whether this change is "easy".

Out of curiosity, why did we have that 4 limit in the first place

Fragile NGen design required us to pick a number. 4 was chosen as a compromise between native image size and performance.

[davidwrighton]

The type dependency tracking isn't yet checked in, but I could revive the prototype. (The data structure I was using is now checked in, so the actual type dependency tracking should be much simpler to put together). Also, as the prototype doesn't actually track related generic instantiations we'd need to look into the cost to do so.

[fadimounir]

You will need to resize the dictionary on all types. It would need to take advantage of the type dependency tracking that @davidwrighton and @kouvel have been working on. I am not sure whether this change is "easy".

Hmm, you are right. Resizing the dictionary on all types is more involved. I'll need to investigate this more...

[fadimounir]

dotnet/coreclr#26262

[jkotas]

Fixed by #32270