none
Where is JIT ? RRS feed

  • General discussion

  • Can you help me with how to find JIT ( Just in Time Compiler ) that Translate Intermediate Language to Machine Code in .Net framework.

    Where is it's executable ? If it's imbedded in windows then in where // In system32 Directory ?

    In software world everything is binary from that theorem JIT is also a piece of binary blob !

    Please Help and I will appreciate your concern!

    Friday, April 8, 2016 6:34 AM

All replies

  • C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll says "Microsoft .NET Runtime Just-In-Time Compiler" in its version resource.

    If you are interested in how the JIT works internally, there is source code in https://github.com/dotnet/coreclr/tree/v1.0.0-rc1/src/jit but I don't know how much that differs from the .NET Framework that Microsoft ships as part of Windows.

    This kind of question would be better asked in the CLR forum.

    Friday, April 8, 2016 7:56 AM
  • https://github.com/dotnet/coreclr/tree/v1.0.0-rc1/src/jit but I don't know how much that differs from the .NET Framework that Microsoft ships as part of Windows.

    Can anyone Confirm this?
    Friday, April 8, 2016 8:56 AM
  • C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clrjit.dll says "Microsoft .NET Runtime Just-In-Time Compiler" in its version resource.

    If you are interested in how the JIT works internally, there is source code in https://github.com/dotnet/coreclr/tree/v1.0.0-rc1/src/jit but I don't know how much that differs from the .NET Framework that Microsoft ships as part of Windows.


    if there is the source code of GIT, I took a look if you compile it will be an application. My Concern is where is the Application in windows ?
    Saturday, April 9, 2016 3:09 AM
  • It's NOT an application.  It is a DLL, just like Ranta said.

    Think for a moment about how this has to work.  When you have a CLR-based application, you have an executable file containing your MSIL code, plus a short stub in native code to start things off.  That short stub initializes the CLR, and then runs the JIT compiler in clrjit.dll.  That compiler compiles your MSIL into machine language in newly allocated memory within your process.  When the compilation process finishes, the pages are marked as executable, and starts running.  When your process finishes, the JIT pages are discarded.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Monday, April 11, 2016 7:29 AM
  • It's NOT an application.  It is a DLL, just like Ranta said.

    Think for a moment about how this has to work.  When you have a CLR-based application, you have an executable file containing your MSIL code, plus a short stub in native code to start things off.  That short stub initializes the CLR, and then runs the JIT compiler in clrjit.dll.  That compiler compiles your MSIL into machine language in newly allocated memory within your process.  When the compilation process finishes, the pages are marked as executable, and starts running.  When your process finishes, the JIT pages are discarded.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Could you give me the offset "short stub of native code" in .net application really stores! 

    Or you can give me an link of article that you know about .Net App internal Architecture please ?

    Thanks In Advance! and especially for the last reply ! :)

    Monday, April 11, 2016 7:51 AM
  • The "short stub of native code" is briefly documented in ECMA-335, 6th edition, §II.25.2.3.1 (PE header standard fields). It just jumps to mscoree!_CorExeMain. If you want to see the code, then use DUMPBIN /HEADERS to find the entry point, and disassemble at that relative virtual address.

    However, Windows does not execute the stub nowadays. It starts the main thread at mscoree!_CorExeMain and not at the native-code entry point of the managed executable. I guess AnyCPU executables would not work otherwise.

    Monday, April 11, 2016 8:34 AM