Shulou(Shulou.com)06/02 Report--

How to analyze the JIT compiler in .net Compact Framework CLR, I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

The topic of .net Compact Framework CLR design has attracted a lot of attention. Now we can take a closer look at the internal structure of .net Compact Framework CLR design from the designer's point of view. In this section, we will discuss the knowledge of the JIT compiler.

Design JIT Compiler

Net Compact Framework CLR design of the * chapter, we will provide you with more in the future, I hope you will pay attention. The JIT compiler of .net Compact Framework differs from .net Framework*** in memory usage. In cases where memory is tight,. Net Compact Framework can release Jitted code and return memory to the operating system. As you might expect, the reason for this design is that the heap used to store jitted code is allocated on the application's private 32MB address space (see the * * section for more information). In addition to the very small private address space, considering that they are never paged and running programs on memory-constrained devices, it is absolutely necessary to design to reduce space pressure if necessary.

When the program is executed, the JIT compiler allocates memory on the heap to store the native code generated by the compilation of each method. Because compilation and memory allocation occur while each method is running, each memory allocation reduces the heap accordingly. In other words, the JIT heap is growing by a small margin. In the process of running the program, the JIT heap will grow to a great extent. In earlier versions of Compact Framework, the size of the JIT heap was limited to a fixed size. In the second version, this restriction has been removed, so the heap will be added when the new method needs to be compiled.

Three things happen that cause most of the space in the JIT heap to be freed and the memory returned to the OS (only "most of the space" here is because the Compact Framework must always retain the jitted code that currently executes the application method). First, if CLR tries to allocate more memory and receives an error from the operating system, the JIT heap will shrink. CLR will think that this failure indicates that there is not enough memory available, so wave as much code in the JIT heap as possible. The act of releasing native code from the JIT heap is determined by the expiration date of the code. Second, when a program is switched to the background, the code is recycled. In Windows Mobile, applications are not usually closed, but are switched to the background. When a program is switched to the background, CLR can obtain more available memory for the foreground program by releasing the code, thus increasing the number of applications running on the device at the same time. * CLR reclaims the jitted code when a managed application receives a WM_HIBERNATE message from Windows CE. When OS finds that the system resources running are too low, it issues a WM_HIBERNATE message. Code recycling in response to WM_HIBERNATE messages is part of CLR's operation to free memory and other resources when device resources are scarce.

When I discuss automatic memory management in a later chapter, you will see that code collection is part of the overall garbage collection.

Figure 1The size of the JIT heap over the lifetime of an application.

Some of the situations in figure 1 are very noteworthy. First of all, the time when the two lows in the figure occur corresponds to the time when the program is switched to the background and the heap size is too large to start code recycling. Again, note that more code is jitted when the program starts than when the program is switched back from the background. This is probably because the application contains some initialization code that is called only at the beginning of the program.

Because CLR discards native code when memory is tight or when the program switches to the background, the same IL code is compiled again by JIT when the program continues to run. That's why we made the second design decision about the JIT compiler: the time to compile IL code usually takes precedence over the quality of generated native code. As an excellent compiler, the Compact Framework JIT compiler makes some basic optimizations, but in order for the application to remain responsive, it is necessary to generate code faster, and more optimizations are required to decide whether or not to execute according to its speed.

One of the key design principles of the JIT compiler is that it does not involve memory usage, which is done to make the JIT compiler easier to port. As I mentioned in the * * section, Compact Framework runs in an environment that requires it not only to run on memory-constrained devices, but also on different processors. .net Compact Framework can currently run on processors including x86, Arm, SH, and MIPS, and can support more processors as required. Because of the need for devices across different areas, JIT compilers are designed to support a new processor type architecture with the least amount of time. One technique used to increase portability is to minimize processor-related operations.

Why no Native Images?

The desktop version of. Net Framework uses a technique called "local mapping" where IL code needs to be compiled by the JIT compiler when the application is loaded. If you take advantage of local imaging technology, the application can start faster. The local image is a file saved on the hard disk that contains the compiled IL code. When .net Framework is installed, it invokes the JIT compiler to generate local CPU instructions for mscorlib, System.Windows.Forms, and other class libraries. When the application starts, the generated native code stored in the local image can be called directly, saving time for JIT to compile these assemblies. Users can also generate local images for their own assemblies (you can refer to the documentation for the ngen.exe tool in .net Framework SDK).

The main reason .net Compact Framework does not use local images is their size. Depending on the local instruction set, the native code size of an assembly compiled by JIT is about three to four times the size of IL code. After compression, the. Net Compact Framework class library is approximately 4.5MB. If the corresponding local image is four times this size, you will see that the storage space required by the local image is a considerable part of the available memory in the device. Another possibility is that the local image can be saved on an external storage card. However, the speed of reading the local image file from the memory card is very slow, so we are not sure that the startup time can be reduced by the local image method.

After reading the above, have you mastered how to analyze the JIT compiler in .net Compact Framework CLR? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.