Proposal: Fixed size thunk pool support

[RalfKornmannEnvision]

As today's game consoles are very strict when it comes to any kind of JIT FEATURE_RX_THUNKS is not an option. But even the Fallback that tries to use a thunk template is not possible. Therefore I need to fall back even more to a thunk pool that have a fixed number of thunks pregenerated set a compile time. The data part could be allocated dynamically but the code needs to be always there.

While my current implementation only works for the switch I noticed that parts of it could be make platform and cpu neutral by using the abstractions layers that are already there.

Would you be interested on an implementation for a general "FEATURE_FIXED_POOL_THUNKS" that should only require an additional assembler file (or two if .S and .asm are needed)  per CPU architecture? 

I will most likely do it anyway to share more code between the different game consoles but I can make it a PR if there is general interest for it

[MichalStrehovsky]

Yes, I think having an option to build with a fixed number of thunks that avoids the memmapping could be useful for some platforms. AFAIK this is how thunkpool actually started, back in .NET Native, but the "you ran out of thunks" exception got old pretty quickly.

Would you be interested on an implementation for a general "FEATURE_FIXED_POOL_THUNKS" that should only require an additional assembler file (or two if .S and .asm are needed) per CPU architecture?

Is the idea that we would set the fixed number of thunkpool thunks at the time the native portion of the runtime is built (i.e. we would need to recompile the runtime if more thunks are needed)?

We could potentially build the specified number of thunks within the AOT compiler (same as we e.g. generate the ReadyToRun assembly helpers).

[RalfKornmannEnvision]

The number of thunks is currently set in one single assembler file that generated the thunks and contains some helper functions. The idea I had was to assemble this file as part of the final executable and link it there. This way the runtime doesn't need to be rebuild every time the number of thunks change. But generating the thunks as part of the AOT compiler sounds like a good idea, too.

[MichalStrehovsky]

That would work too. Doing it in the compiler has the advantage of not needing an extra tool, but I guess this is enough of a corner case scenario that it doesn't matter - people who target consoles need to have all sorts of tools installed.

[RalfKornmannEnvision]

I like the idea to let the compiler do this work. This would eliminate one more step that could go wrong. Writing games for Game Consoles with C# should be easier not more complicated than with the regular C++ based SDKs.