. NET compiler Technology Insider (2)

Compile. NET compiler Technology Insider (2)
Author: builder.com
Tuesday, April 2002 12:23 PM

As a code directives platform, Microsoft. NET is more complicated than any other technology platform previously unveiled by Microsoft. Because. NET provides support for multiple programming languages and, in theory, multiple platforms, which requires adding an intermediate layer of code to the traditional two-tier code layer. In this case, the traditional two tiers are the source code layer and the compiled native code layer. The newly added code layer is given. NET platform provides additional flexibility, but in turn adds to the complexity of the system. In addition, thanks to the emergence of this new layer of code, a series of novel application deployment options have been presented to programmers for the first time. The gist of this article is to lead. NET application developers understand the code compilation process of. NET, and understand the additional compilation options.

. NET is different: MSIL
at Microsoft. NET framework, applications can be written and created in a variety of advanced programming languages, such as vb.net, C #, and COBOL. NET and so on, you can write. NET applications. And through every kind of observance. NET Standard programming language The program code written in the first step from the source code to the common standard language of. NET: MSIL (Microsoft Intermediary Language: Microsoft intermediate Language). MSIL itself is a complete, object-related language, and only it is possible to create an application. To get a general idea of some of the things about MSIL, you can see the article "Understanding the workings of the CLR through the MSIL language". NET applications are in the form of MSIL and are compiled into native code only through the Just-in-time compiler (JIT) when the program executes. Figure A illustrates this process.

Figure A



. NET's compilation process: from source code to native instruction


JIT-compiled as soon as the Assembly code is loaded, which can be seen as an assembly-level compilation (see the "assembly-Cure" DLL Hell "for more details on Assembly technology? "article). During compilation, the JIT compiler loads the corresponding program for each method declaration of the matching object once it encounters an object's index for the first time. In this way, the IL is compiled at a later time when the method is called, and the corresponding root program of the method is replaced by the address of the method's compiled code. This process occurs each time the method is first invoked, and the resulting native code is buffered so that it can be used the next time the assembly code is loaded during the session. Obviously, this instruction system requires a lot more processing power than the traditional compiled language, but it's not as high as you think.

It is important to clarify a misconception that is widely misunderstood, and that is what many people think. NET application is an interpreted, not compiled, program. In addition, there are common misconceptions that JIT-compiled code is stored on disk and can be executed for the same application. It's not possible to do this, but you'll soon understand that this is not the default compilation scenario. The IL code of an application is actually recompiled every time the application is run to native code.

Two types of compilers
In fact, the JIT compiler is divided into two types (economic compilers and ordinary compilers), and they are not inherently equal. The economic JIT compiler represents the minimum functionality required to run a. NET application, replacing each MSIL instruction directly with Peer-to-peer native code without any optimizations and resulting in less system load. This also means that it is mainly used in memory and other resources more nervous platform.

The generic JIT compiler, on the other hand, is the default Run-time configuration, which optimizes the code it produces. This has been given virtually. NET goes beyond the traditional precompiled language: A precompiled language can only make a rough estimate of what the code it is working on will run on its platform. The JIT compiler can be accurately tuned to the current run-time state, resulting in work that cannot be accomplished by some precompiled languages:

More efficient use and allocation of CPU registers
Implement low-level code optimizations where appropriate, such as constant overlap, copy copying, cancellation of range checking, cancellation of conventional alternate expressions, and method inline
Monitor current physical and virtual memory requirements for more efficient use of memory during code execution
Generate specific platform directives to accurately and fully utilize the actual processor pattern

. NET compilation results in that the additional load requirements generated by JIT do not have a significant performance penalty.

Performance Options
This means that the MSIL is JIT-compiled every time the application is run. Remember, this is common sense, and then, based on the principles described in the above, it is clear that when you start the application and use the Non-core functionality for the first time, it obviously leads to a lower performance than the optimization level. So what should you do to minimize this negative effect?

Microsoft's response is to provide us with a compiler called Pre-jit (also known as Native Image Builder: Native image Generator, which is therefore Ngen.exe). On the surface, at least it is a treatment for any performance problem. The Pre-jit compiler is invoked before runtime, and when installed, it compiles all assembly forms of MSIL to native code. This native code is then stored in a special part of the global Assembly cache (the global Assembly cache) for later use, completely bypassing the JIT compilation process.

At first glance, this should be a solution to the previous problem, especially for client code. But, do you remember? Ordinary JIT implements a number of just-in-time optimizations when compiling MSIL. Many of these optimizations, especially those involving registers and memory usage, are driven by the system's current requirements. As a result, the effort to compile assembly code in batches will prevent these optimizations from going on and actually generate slower final code. Before you take this approach, Microsoft's advice is to set your JIT and NGen versions to the same assembly level on the target platform, using the current conditions under normal compilation.

Unless you're a hardcore fan of java. NET's run-time behavior and compilers will be completely different from the same kind of situation you used to know. But they are not mysterious things either. I hope my exposition will clarify some of the problems that have puzzled you.