Chapter 2 theoretical basis of. net Programming pioneer C #-Public Language Runtime Environment

Chapter 2 theoretical basis-Public Language Runtime Environment
Now that you are fully impressed by C #, I want to give you a full picture of NGWS runtime. C # depends on the runtime provided by NGWS. Therefore, it is necessary to know how the runtime works and the concepts behind it.
Therefore, this chapter is divided into two parts-they are the basis of all concepts and usage. Although the two parts overlap, they help to deepen understanding of the concepts being learned.

2.1 NGWS Runtime
NGWS and NGWS Runtime provide you with a Runtime environment. This runtime manages the Execution Code and provides services that make programming easier. As long as your compiler supports this runtime, you will benefit from this Managed execution environment.
You can guess that the C # compiler supports NGWS runtime correctly, but not only does it support NGWS runtime, but it also supports VB and C ++. These codes created to support runtime are called managed code ). The following are the benefits your application has gained from NGWS runtime:

Cross-language integration (using general language specifications)
Automatic Memory Management (garbage collection)
Cross-language Exception Handling (uniform expansion)
Enhanced security (including type security)
Version support ("DLL hell" Terminator)
Simplified component Interaction Mode

Because NGWS runtime must provide all these benefits, the compiler must issue the Metafile along with the managed code. The metadata file describes the type in the code. It exists with your code (similar to PE-PE is a variable-bit execution file)
As you can see from many cross-language functions, NGWS runtime is mainly about tight integration into SS multiple different programming into ages ). This kind of support allows you to derive a C # class from a VB object (I will discuss it later ).
C # A feature programmers will like is that they don't have to worry about memory management-that is, they don't have to worry about notorious memory leaks. NGWS runtime provides memory management. When the life cycle of objects and variables ends (no longer referenced), the garbage collector releases them. I really like this feature, because memory management in COM has always been a heart disease for me.
You should be encouraged to configure a management application or component. Because the management application contains metadata files, NGWS runtime can use this information to ensure that your application has various required versions. The obvious result is that your code is rarely interrupted because it does not depend on each other.
The remainder of this chapter is divided into two parts, each of which discusses various aspects of NGWS runtime until your C # application can be executed.
1. Intermediate Language (IL) and metadata
2. Instant Compiler (just-in-time compliers)

2.1.1 intermediate language and metadata
The managed code generated by the C # compiler is not the original code, but it is the intermediate language (IL) code. This IL Code itself becomes the entrance of the NGWS runtime Managed execution process. The obvious advantage of IL code is that it is CPU-independent, which means that you must use a compiler on the target machine to convert the IL code into the original code.
Although the IL code is generated by the compiler, it is not the only thing the compiler provides to the runtime. The compiler also generates metadata about your code, which tells the runtime more about your code, such as definitions of various types, signatures of various types of members, and other data. Basically, metadata is the type library, registry content, and other information used for COM. Even so, metadata is directly merged with the Execution Code and is not isolated.
Iland metadata are stored in files that extend the pegex format (the pegex is used in .exe and. dll files ). When such a PE file is loaded, metadata and IL are located and separated from the file during the runtime.
Before proceeding, I would like to give you a short directory of the existing IL commands. Although it is not a complete list and you do not need to memorize and understand it, it lists the knowledge base you need for the C # program.

Arithmetic and logical operators
Control Flow
Direct Memory Access
Stack operations
Parameters and local variables
Stack allocation
Object Mode
Instance type value
Critical Section
Array
Classification position
Instant Compiler (JITters)

2.1.2 instant Compiler (JITters)
The managed code generated by C # or other compilers that can generate the managed code is the IL code. Although the IL code is encapsulated in a valid PE file, you still cannot execute it unless it is converted into the managed original code. This is the time when the NGWS runtime instant Compiler (also known as JITters) is amazing.
Why are you tired of compiling code in real time? Why don't you compile the entire il pe file into the original code? The answer is time-the time when the IL code needs to be compiled into the CPU specification code. This compilation will be more efficient, because some program segments have never been executed. For example, in my word processor, the Mail Merge function has never been compiled.
Technically, the entire process is as follows: when a type is loaded, the loader creates a stub and connects it to each type of method. When a method is called for the first time, the stub gives the control to JIT. JIT compiles IL as the original code and points the pointer to the buffered original code. The subsequent call will execute the original code. At some point, all the IL is converted into the original code, and the JITter is idle.
As I mentioned earlier, there are many JIT compilers. On Windows, NGWS runtime has three different JIT compilers.
JIT -- this is the default JIT compiler used by NGWS runtime. It is a back-end optimized compiler that performs Data Flow Analysis on the frontend (up front) and creates a highly optimized and managed original code for output. JIT can use less rigorous IL instruction set encoding, but the required resources will be considerable. The main limits are the memory footprint, the result working set, and the time consumed by optimization.
Economy JIT -- compared with the main JIT, EconJIT aims to convert IL into the managed original code at high speed. It allows buffering of the original code, but the output code is not as optimized as the code generated by the main JIT (the code is small ). When the memory is insufficient, the advantages of the quick code generation solution will disappear. By permanently throwing away useless JIT code, you can mount a larger IL program into the code buffer. Because JIT compilation is fast, the execution speed is still fast.
PreJIT-although it is based on the main JIT, it operates more like a unified compiler. After you install the NGWS component, you can run it to compile the IL code into the managed original code. Of course, the final result is faster loading time and faster application startup time (no more JIT compilation is required ).
In the listed JITters, there are two JITters at runtime. But how do you decide which JIT to use and how to use the memory? There is a small application (jitman.exe) called "JIT compilation manager", which is stored in the bin directory under the ngws sdk installation directory. When the program is executed, it adds an icon to the System Task Bar and double-click the icon to open the program dialog box (see figure 2.1 ).

Figure 2.1 JIT compilation Manager allows you to set various performance options

Although it is a small dialog box, the options you select are quite powerful. Each option is described below.
Use Economy JIT only option -- if this check box is not selected, NGWS runtime uses the default normal JIT compiler. I have explained the differences between the two JITter types.
Max Code Pitch Overhead (%) option -- this setting is reserved only for the economy JIT. It controls the JIT compilation time and the percentage of code execution time. If the value of the specified domain is exceeded, the Code buffer is expanded to shorten the time consumed by JIT compilation.
Limit Size of Code Cache option -- this option is not selected by default. If this option is not selected, the buffer will use the memory it can obtain. If you want to limit the buffer Size, check this option, which allows you to use the Max Size of Cache (bytes) option.
Max Size of Cache (bytes) Option-controls the maximum value of the buffer that holds JIT code. Although you can strictly limit this value, you should be careful not to exceed the maximum value suitable for this buffer zone. Otherwise, the JIT compilation of this method will fail.
Optimize For Size Option-tells the JIT compiler that the optimization is intended to make the code smaller than to execute faster. This setting is disabled by default.
Enable Concurrent GC [garbage collection] Option -- garbage collection (GC) runs in the user code thread by default. This means that when GC occurs, you may notice a slight latency in the response. To prevent this problem, open the current GC. Note: the current GC is slower than the standard GC. It is only valid when writing on windows 2000 (the time of writing.
When using C # To create a project, you may have tried it using different settings. When creating a UI-intensive application, you will see the maximum difference that allows the current GC.

2.2 Virtual Object System (VOS)
So far, you have only seen how NGWS runtime works, but you do not know the technical background of NGWS and why it works like this. This section describes the NGWS Virtual Object System (VOS ).
The following are the NGWS runtime rules when a type model is declared, used, and managed in VOS. The idea behind VOS is to build a framework that does not sacrifice performance when executing code, allowing cross-language integration and type security.
The framework I mentioned is the basis of the runtime architecture. To help you better understand it, I hooked it out of four areas. It is important to understand C # applications and components.
VOS type system-provides a wide range of type systems, which are intended to support full implementation of comprehensive programming languages.
Metadata-describes and references the types defined by the VOS type system. The permanent format of metadata is irrelevant to the programming language. However, metadata is used as an nterchange mechanism, which is between the virtual execution system of the tool and NGWS.
General language specification (CLS)-CLS defines a subset of types in VOS, and also defines general usage. If a class library complies with the CLS rules, it ensures that the class library can be used in all other programming languages that can implement CLS.
Virtual Execution System (VES)-This is a real-time implementation of VOS. VES is responsible for loading and executing the program compiled when NGWS is run.
These four parts constitute the NGWS runtime architecture. Each part is described in the following section.

2.2.1 VOS
VOS provides a wide range of types, which are intended to support full implementation in multiple programming languages. Therefore, VOS must support both object-oriented and procedural programming languages.
Currently, there are many similar but somewhat incompatible types. Take an integer as an example. In VB, it is 16 bits long, and in C ++, It is 32 bits. There are more examples, especially data types used in date and time and databases. This incompatibility makes application creation and maintenance unnecessary, especially when the program uses multiple programming languages.
Another problem is that, because there are some differences between programming languages, you cannot reuse the types created in another language. (COM partially solved this problem using the binary standard interface ). Today's code reuse must be limited.
The biggest obstacle to publishing applications is the inconsistent object models of various programming languages. There are differences in almost every aspect: events, attributes, permanent persistence, and so on.
VOS will change this phenomenon. VOS defines the type of the description value and specifies a contract that must be supported by all values of the type. By