Understanding JIT behavior for generic methods with reference type parameters

[ashmind]

Hi! I am trying to understand how generic methods are jitted (value types vs reference types), so that I can find them properly in SharpLab. Value types seem quite straightforward, but I am running into some confusion with reference types.

Let's take this method M:

static class C {
    static T M<T>() => default(T);
}

I created M<int> and M<string> using MakeGenericMethod, then called RuntimeHelpers.PrepareMethod() on both.
I have then saved a minidump using VS save dump feature.

M<int> (value type)

If I start with M<int> method, by get these pointers from MethodInfo

M<int> MethodHandle: 0x00007ff9876dcfc0
M<int> MethodHandle.GetFunctionPointer(): 0x00007ff9876d0480

and start looking at it in WinDbg, I get the following:

0:016> !DumpMD 0x00007ff9876dcfc0
Method Name:          C.M[[System.Int32, System.Private.CoreLib]]()
Class:                00007ff9876dcc18
MethodTable:          00007ff9876dcd30
mdToken:              0000000006000001
Module:               00007ff9876dc080
IsJitted:             yes
Current CodeAddr:     00007ff9876d0480
Version History:
  ILCodeVersion:      0000000000000000
  ReJIT ID:           0
  IL Addr:            000002252c020250
     CodeAddr:           00007ff9876d0480  (Optimized)
     NativeCodeVersion:  0000000000000000

IsJitted is yes, CodeAddr matches output of GetFunctionPointer(), all looks well.
I can easily find the jitted method:

0:016> !u 0x00007ff9876d0480
Normal JIT generated code
C.M[[System.Int32, System.Private.CoreLib]]()
ilAddr is 000002252C020250 pImport is 0000021DA6555C80
Begin 00007FF9876D0480, size 3
>>> 00007ff9`876d0480 33c0            xor     eax,eax
00007ff9`876d0482 c3              ret

M<string> (reference type)

For M<string> I can get the following pointers

M<string>.MethodHandle: 0x00007ff9876dd250
M<string>.MethodHandle.GetFunctionPointer(): 0x00007ff9876d00b8

Then, in WinDbg

0:016> !DumpMD 0x00007ff9876dd250
Method Name:          C.M[[System.String, System.Private.CoreLib]]()
Class:                00007ff9876dcc18
MethodTable:          00007ff9876dcd30
mdToken:              0000000006000001
Module:               00007ff9876dc080
IsJitted:             no
Current CodeAddr:     ffffffffffffffff
Version History:
  ILCodeVersion:      0000000000000000
  ReJIT ID:           0
  IL Addr:            000002252c020250
     CodeAddr:           0000000000000000  (Optimized)
     NativeCodeVersion:  0000000000000000

As we can see, somehow is IsJitted is no, and there is no code address, even though I called PrepareMethod.

Now if I look at the pointer from GetFunctionPointer():

0:016> !u 0x00007ff9876d00b8
Unmanaged code
00007ff9`876d00b8 e973ef0000      jmp     00007ff9`876df030

If I follow that jump

0:016> !u 00007ff9`876df030
Unmanaged code
00007ff9`876df030 48b950d26d87f97f0000 mov rcx,7FF9876DD250h
00007ff9`876df03a 48b8d8d16d87f97f0000 mov rax,7FF9876DD1D8h
00007ff9`876df044 488b00          mov     rax,qword ptr [rax]
00007ff9`876df047 ffe0            jmp     rax

And follow the second jump, I get to the "Normal JIT generated code"

0:016> dq 7FF9876DD1D8h
00007ff9`876dd1d8  00007ff9`876d04c0

0:016> !u 00007ff9`876d04c0
Normal JIT generated code
C.M[[System.__Canon, System.Private.CoreLib]]()
ilAddr is 000002252C020250 pImport is 0000021DA5D8DEF0
Begin 00007FF9876D04C0, size 3
>>> 00007ff9`876d04c0 33c0            xor     eax,eax
00007ff9`876d04c2 c3              ret

So seems like method is jitted?
(Canon here makes sense due to generic code sharing)

Questions

Looking at this, I can't quite understand a few things:

1. Why does MethodDesc say that M<string> is not jitted, when it ends up in jitted code? (through __Canon)
2. What do those jumps do? I would understand JIT stubs, but they seem to lead to a jitted method?
3. Is there a way to get to the jitted code from M<string> MethodHandle without following all the jumps?

[EgorBo]

Perhaps, an intermediate method that sets the generic context to String since you originally requested for M<String>?

Btw, have you ever considered using a Checked version of runtime in order to use DOTNET_JitDisasm=<method-name> - it works even for generics and displays a lot of useful information such as meaningful names for all calls including helper ones, e.g.:

vs:

[ashmind]

Perhaps, an intermediate method that sets the generic context to String since you originally requested for M?

That would make sense for the second jump, but then why the first one?

use DOTNET_JitDisasm=<method-name>

Fair point, thanks -- I'll consider it. But for now I am still curious on how this (ref-generics) works with JIT, even if I end up using a different approach.