Keept NATIVE code on HDD

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

When JIT compiles MSIL code to NATIVE code, this NATIVE code is not kept on
the hard disk? To use it at the restart of application?
If it so, why Microsoft will not make it, for increase of productivity?

P.S. Sorry of my english
 
When JIT compiles MSIL code to NATIVE code, this NATIVE code is not kept on
the hard disk? To use it at the restart of application?
Click to expand...

Right, it doesn't.

If it so, why Microsoft will not make it, for increase of productivity?
Click to expand...

There's a tool called Ngen.exe that basicly does what I think you
want.



Mattias
 
Hi Matthias!

There's a tool called Ngen.exe that basicly does what I think you
want.
Click to expand...

One has to keep in mind that generating native images at deployment time
sounds attractive,
but in fact it has serious downsides.

One reason not to cache native images is the bigger code size of the IA-32
maschine code. A typical component normally only uses a small number of
methods. After generating native code the new IA-32-dll will contain the
native code for every method, even methods that may never or seldomly be
called, e.g. error-handling code. The overall in-memory code will grow
needlessly, but even worse: the placement of the method bodies does dot
represent the dynamics of the running program. Each of the small number of
methods the program actually needs may be located in different virtual
memory pages. This fragmentation has a negative effect on performance. You
will also bypass the performance optimizations of the CLR based on
heuristics.

The second issue regarding the use of ngen has to do with cross-component
contracts. All types that are used by a method must be visible to the JITter
to generate the native code because the native code has to contain
non-virtual offsets just like C, C++, COM and Win32 contracts. Now even if
only one type definition in one of the dependend components changes you
might have a problem. The other component might invalidate the cached native
code.

For that reason every module is assigned a "Module Version Identifier"
(MVID) at compilation time which is simply a unique identifier to make sure
it is unique for every compilation of a certain module. When the CLR
generates and caches the your native image, the MVID of every module used to
generate the native image (including those from every external assembly) is
stored with the native code. When the CLR-loader tries to load a cached
native image it checks the MVIDs that were used to generate the native
image. If a recompilation of any module has taken place then the CLR ignores
the native image and takes the CIL-version again.

Cheers

Arne Janning
 
Back
Top