Caching runtime generated code. RU patent 2520344.

FIELD: physics, computer engineering.

SUBSTANCE: invention relates to runtime generated code. A program entity that generates code but does not alter global state is identified. Code produced by the identified program entity can be assigned an identifier and cached the first time it is executed. Subsequent executions of the program entity can allow generation of the code and/or translation of the generated code into native binary code. The runtime generated code and native binary code can be cached in a machine-wide cache, or can be added to the metadata of the assembly generated from the source code of the program entity.

EFFECT: caching runtime generated code.

15 cl, 6 dwg

The level of technology

Traditionally compilers software make your own code, i.e. the binary code that is dependent on the machine on which this code will run. Native (unmanaged) code produced by conventional compilers typically includes everything that is required by the system to run this code, and a small addition. In contrast, in virtual machine environments source code is compiled into an intermediate bytecode representation, which is not dependent on any particular machine. In addition, the output of the compiler managed code typically includes much more information than just the binary code. For more information describes the characteristics of binary code and is sometimes called metadata: a General term for data that describes other data, where in this case the described data is binary. The container that contains intermediate byte-code and metadata, sometimes called a managed Assembly. These containers can also be named class files, Java archives or Java modules. The term "Assembly" or "managed Assembly"as used in this application, refers to any such container byte code and metadata.

In an unmanaged environment during the execution of pre-existing native commands are loaded into memory and executed. In a managed environment during the execution of a managed Assembly can be compiled or translated into native binary instructions immediately before execution. That is, managed Assembly can be loaded into memory and compiled dynamic (JIT) or dynamic compiler into machine-dependent and dependent on the operating environment of the instructions, which are then executed. While the compile phase/broadcast managed environment includes additional processing that may influence on the performance, on the one hand, JIT/dynamic compiler may be able to do-dependent environment optimization, an advantage of which might not use unmanaged environment. For example, if JIT/dynamic compiler is aware of the fact that the code is executed, run with full trust, it can miss some consuming checking of the system of protection that can not be missed in the unmanaged environment.

In a managed environment, rather than compiling a managed Assembly, before it will run, the source code or intermediate byte-code can be compiled into native binary representation of an optimizing compiler and saved (cached)before you can be running on the machine executing the requested program. For example, the image generator in your own code, such as NGEN, can produce its own binary image for the environment, converting intermediate byte-code to native machine instructions in a binary file, before the request is accepted for Assembly. Thus, the previously existing executable code can be loaded and running with the second phase of compilation broadcast in a manner similar to the way traditional environment own code. Although caching is to make the Assembly to execute faster, removing the JIT process/dynamic compilation/broadcast during the execution, performance may not improve as optimization, depending on the environment, carried out JIT/dynamic compiler, such as optimization, described above, cannot be made when the pre-caching assemblies.

As stated above, most native languages do not keep track of information about the internal structure of the source code. In contrast, because the metadata is included with intermediate byte-code that is produced in managed environments code that takes advantage of the currently existing objects, create new objects, shall inherit from existing objects, etc. can be easily generated at run time. Generated during the execution of the code can have the need for special mechanism should be used to create or load dynamic code without loading the generated during the execution of code with the constant storage media. Such a mechanism will be generated as display (Reflection Emit) in the remainder of this document. The code that is generated at run time, which is also called dynamically-generated code is typically compiled during each individual case the process of intermediate byte-code and then processed JIT/dynamic compiler. It is the production costs, which can be significant.

Disclosure of the invention

If an object such as a managed Assembly or part of a managed Assembly, such as the method or function that generates additional code at run time, if this method or function are clean, generated additional run-time code is cached, so subsequent executions of the cached object is generated at run time code could be retrieved from the cache search ID and removing the identified code from the cache, skipping one or more phases of code generation. Additionally, the cached code can be compiled by a compiler and/or can be added as additional data to the metadata of the original Assembly. So the generated at run time code can be cached and reused in all copies of the programs you run. During the execution of one or more caches generated at run time code is scanned, and if identified the object is in the cache, it is loaded and used by eliminating phase generate the intermediate bytecode, the compile phase/broadcast or both phase of generation of intermediate byte-code and compile phase/broadcast.

This entity is designed to provide a choice of concepts in a simplified form, which further described below in the detailed description. This entity is not intended to identify the key characteristics or essential features of the claimed subject matter of the invention and is not meant to be used to limit the amount of the declared object of the invention.

Brief description of drawings

The drawings:

Figure 1 - block diagram of the system example for caching of generated during the execution of the code in accordance with the aspects of the object of the invention disclosed in the materials of this application;

Figa - how to run a dynamic program, as it is known in the art;

Fig.2b is an example of a way to cache the generated during the execution of the code in accordance with the aspects of the object of the invention disclosed in the materials of this application;

Figs is another example of a way to cache the generated during the execution of the code in accordance with the aspects of the object of the invention disclosed in the materials of this application;

Figure 3 is a block diagram that illustrates an example of a computing environment that can be applied aspects of the subject matter disclosed in the materials of this application; and

Figure 4 is a block diagram of the example of the integrated development environment in accordance with the aspects of the object of the invention disclosed in the materials of this application.

Detailed description

Overview

Reflection emit is a mechanism that allows you to create dynamically at run time and to use additional software instructions. That is, software architecture can be determined at run time based on the data, services, and individual operations that are relevant to run. For example, suppose that your program performs mathematical operations and the user wants to perform calculations based on the matrix of a certain size. One approach is to write the generating function that allows to perform calculations for matrices with any size. This function is static because the algorithm by which it operates, directly addresses the desired problem. Such a program should probably have low productivity because one of its requirements is to work on any size of the matrix. Alternatively, dynamic solution may include the generation of custom algorithm for solving the problem. Such a decision would include static function And which to set different input arguments would use some of these arguments to generate a new dynamic feature In, and then pass various arguments for this dynamic functions. This special dynamic function satisfactorily would work only in specific input data, but it could be written in a way that would allow to have the best performance in the presence of such limited input set. For example, a static function And can accept a request by multiplying each other two matrices 16x16. Static function And can generate a new dynamic function B, which only allows the multiplication of each other matrices 16x16. Then static function And may delegate to the dynamic function In the actual task of matrix multiplication each other.

When using such a mechanism as a reflection emit at runtime can be made additions to the software instructions programmatically (dynamically). I.e. in order to continue the example above, using a mechanism such as reflection emit, to the original software instructions at runtime can be done optimization programmatically (dynamically) to optimize this particular program execution for a 16x16 matrix. Dynamic modification made by the mechanism, such as reflection emit, can improve productivity, increase compatibility or provide other useful advantages. Within the context of object-oriented environment reflection emit enables creation of new types and new methods on the types and can specify the algorithm that implements new methods. Within the environment of managed code intermediate byte-code can be generated through reflection emit. In the famous existing systems generated during the execution of the intermediate byte-code must be compiled/converted into native machine instructions each time you run the program.

In accordance with the aspects of the object of the invention disclosed in the materials of this application, when a dynamic program starts for the first time, creates intermediate byte-code, set identifier, irrespective of the execution context, and the code is cached. When the program is started the next time, the intermediate code should not be redrawn. For example, suppose there is a dynamic function (i.e. a function that generates intermediate byte-code at run time). Let's further assume that the function takes two arguments, which may or may not vary between executions of the function. Depending on the values accepted arguments will be created in a variety of intermediate byte-code. In accordance with the aspects of the object of the invention disclosed in the materials of this application, ID, based on the values of the argument and the name of the dynamically generating code functions that can be created and associated with intermediate byte-code produced by this function. Identified bytecode can be cached by any cache intermediate byte-code, or in the part of the Assembly's metadata, so that the next time the function is executed with the same values for arguments, cached byte-code can be retrieved from the cache and loaded directly into memory, eliminating the need for re-generate the intermediate bytecode. Similarly identifier for dynamic functions can be based on the argument values that are defined for the function that generates the dynamic function. The identifier for the cached dynamic functions can be based on the algorithm that uses the generating function for generating dynamic functions. The identifier for the dynamic function can identify a specific version of dynamically generating function code.

Moreover, if intermediate byte-code is converted to native code, native code can be cached by any cache own code or in part metadata original Assembly. When the program is executed the next time, should not be performed either generate intermediate byte-code or convert byte code into native binary code. Own binary code can be loaded and executed directly from the cache of your own code. Cached own binary code can be identified, as described in the preceding paragraph.

Caching of generated at run time code

Figure 1 illustrates an example of a system 100, which caches generated during the unrest code, in accordance with the aspects of the object of the invention disclosed in the materials of this application. System 100 may include one or more of the following: one or more components of 120 that caches generated during the execution of the code and/or carry out a search operation in the cache generated during the execution of the code, such as the cache 109 intermediate byte-code and/or cache 118 repeatedly used the .exe file (native code) and/or cache 122 source, Assembly, and return the identified code to the requester, the compiler 105, JIT or dynamic compiler 110 and one or more caches, such as the cache 109 intermediate byte-code and/or the cache 118 repeatedly used the exe (machine code) and cache 112 original Assembly. JIT or dynamic compiler can generate in memory running, but which is not reusable own code. Input arguments, such as input arguments 113, can be supplied when you should be running.

The compiler 105 can compile the source code 104 in one or more managed assemblies 108 etc. Source code 104 may include dynamic code, i.e. the code that, when executed, generates additional code at run time, such as generated during the execution of the intermediate byte-code 111. The managed Assembly can include intermediate byte-code 106 and metadata 107. Metadata 107 may include information concerning custom attributes that identify if an object such as the Assembly or the Assembly part, such as a function or a method of Assembly, generates code at run time, and if the object is suitable for caching. In General, the program object that is suitable for caching, does not change the global state. This object is called the "clean" or "purely functional". For example, a pure function does not change the global state. Metadata can be placed in the generating function in the data argument that is passed to the generator of dynamic code or in another place. The original Assembly can be maintained in the cache (the library) source build, such as the cache 122 original Assembly.

As it is known in the art, when the Assembly met, the Assembly is loaded into memory. If pre-generated exe file is available (created by the image generator in your own code, such as NGEN 112, for example), native binary representation can be loaded and executed. If pre-generated exe file is not available, JIT, or a dynamic compiler 110 can convert a managed Assembly 108 unsuitable for re-use native binaries 114 in memory. In the known systems, even if the program itself was previously compiled into native binary format, the code that is generated by the program during execution must be re-compiled each time the program runs. Called mechanism, such as reflection emit, which generates additional code (for example, reflection emit generates intermediate byte-code, such as generated during the execution of the intermediate byte-code 111 using additional information stored in the Assembly's metadata). Generated during the execution of the intermediate byte-code 111 is generated, and JIT, or a dynamic compiler converts generated during the execution of the intermediate byte-code into unsuitable for re-use native binaries 114 (native code).

In contrast, in accordance with the aspects of the object of the invention disclosed in the materials of this application, generated during the execution of code in some circumstances can be cached (for example, in the cache 109 intermediate byte-code and/or cache 118 repeatedly used the .exe file (native code) and/or cache 122 original Assembly). For example, suppose the program includes net function which generates additional code at run time. Pure function as used in the materials of this application refers to the function that does not change the global state. For example, suppose the function And takes two arguments, the argument and the argument b. Intermediate code generated when the function And is called with an argument = value 1 and the argument b = the value of 2, and has the same result. Therefore, the creation of specific identification method for generating code at run time, for specific values of the argument or arguments (dependent from performance characteristics) for this method and caching the generated intermediate code generation intermediate language can be eliminated for subsequent calls to this function.

So when the function is executed the first time, the intermediate language can be generated identified and cached. When the function is executed a second time, the value of 1 for the a and the value 2 for the argument b, intermediate code does not need to be generated, because he was cached. Instead intermediate code identified by the function name and argument values can be retrieved from the cache with key ID. Moreover, if your code was generated from the intermediate code (for example, through the generator of images in native code, such as NGEN), native code may be retrieved from the cache machine code, eliminating the need to generate intermediate byte-code and the need to generate native machine code of the intermediate bytecode.

Can be worked out common scenarios, and can be produced intermediate byte-code, which is usually generated and/or can be made and pre-cached native binaries. In accordance with some aspects of the subject matter disclosed in the materials of this application, intermediate byte-code and/or proprietary binary image can be included as additional metadata in the Assembly, so that even when the Assembly first time it is run on the user's machine, and the cache intermediate bytecode scale machines and/or cache own binary machine code is empty, intermediate bytecode or native binary file can be found in the Assembly. In accordance with some aspects of the subject matter disclosed in the materials of this application, Assembly, which was updated dynamically generating code function can accept a new version number and/or previous (unpatched or source) cache information for this Assembly can be discarded or not used.

Figa shows how to generated during the execution of the code, as it is known in the art. At the stage 202 source code containing dynamic program (a program that produces generated during the execution of the code), can be compiled by a compiler, such as the compiler, as described above, in relation to the figure 1. The output of the compiler can be the Assembly that contains intermediate byte-code and metadata associated with the produced intermediate byte-code. At the stage 204 can be accepted a request of the Assembly. At the stage 206 Assembly can be loaded into memory. At the stage 208 can be determined based search key ID, if available precompiled own binary .exe file. At the stage 210 the search process may determine that its own binary .exe file is available and can be downloaded and run your own binary .exe file. At the stage 208 search can determine what precompiled own binary .exe file is not available.

In response to this definition phase 212 JIT or dynamic compiler can compile or broadcast intermediate byte-code into its own binary, download and execute the binary. At the stage 214, or a precompiled or JIT compiled, dynamic program can be executed. At the stage 216 dynamic program can generate additional code, as it is a challenge mechanism, such as a reflection emit. This generated at run time code can be generated by a generating reflection as an intermediate bytecode. Before generated at run time code can be executed, it must be compiled into native binary code JIT or dynamic compiler. There is no way to pre-compile the generated during the execution of the code, and there is no way to create your own binary .exe file to be generated at run time code.

Fig.2b illustrates an example of a way to cache the generated during the execution of the code in accordance with the aspects of the object of the invention disclosed in the materials of this application. At the stage 302 may be requested generation software object, such as a dynamic program or part of a program, such as dynamic method or function. The program object, suitable for caching may be determined by the presence of a specific index in the metadata associated with the method, i.e. generated by the software object. The method or function that are appropriate to their results are cached, are not changing global state. The method or function that does not produce unexpected change the global state, called a "clean" method (or "clean" function). In accordance with the aspects of the object of the invention disclosed in the materials of this application, a pointer to such a method or function can be custom attribute. At the stage 304 ID can be derived or generated in accordance with set algorithm or schema.

At the stage 306 first the cache, such as the cache intermediate byte-code can be viewed on the presence of an identified program object. If at the stage 308 calculated identifier is not found in the first cache (for example, the cache intermediate byte-code), at the stage 330 can be examined by a second cache. Secondary cache can be a cache of its own binary code. On stage, 332, if identified a software object is found in the secondary cache, your own code can be checked against the results of the search in the cache intermediate byte-code to determine whether it has the same version as in the cache intermediate code and 346, if your code is a topical (for example, it has the same version as the intermediate bytecode at the stage 344 identified for the program object), binary with native code can be loaded and executed. If at the stage 332 identified the program object is not found in the secondary cache (native code), the native code can be generated (JIT, or a dynamic compiler, or NGEN for further caching) at the stage 334, loaded and executed on the stage 336 and, if generated NGEN cached on the stage 338.

If at the stage 308 intermediate code for a program object is not found in the primary cache, at the stage 340 intermediate code can be generated on the stage 340 (for example, using reflection emit) and cached on the stage 342. After you generate the intermediate code on stage 340, secondary cache can be viewed on stage 330 for the presence of a software object. Secondary cache can be a cache of its own binary code. On stage, 332, if identified a software object is found in the secondary cache, your own code can be checked relative to the search results in the cache intermediate byte-code to determine whether it has the same version as in the cache intermediate code on stage 344 and 346, if your code is a topical (for example, the same version as intermediate byte-code for the software identified object), binary with native code can be loaded and executed. If at the stage 332 identified the program object is not found in the secondary cache (native code), the native code can be generated (JIT or dynamic compiler or NGEN for further caching) at the stage 334, loaded and executed on the stage 336 and, if generated NGEN cached on the stage 338. Will be taken into account that the cache own binary code may be within the Assembly itself, or may be a cache scale machines. This way will be taken into account that the first cache can be a cache intermediate byte-code or cache the original Assembly.

In accordance with the aspects of the object of the invention disclosed in the materials of this application, with reference to pigs on stage 306 first the cache, such as the cache own binary code, can be viewed on the presence of an identified program object. If at the stage 308 calculated the ID is found in the first cache (for example, the cache own binary code), at the stage 324 own binary code can be retrieved from the cache own binary code that is loaded and executed. If the computed ID is not found in the first cache (for example, the cache own binary code), the search can be performed in the second cache (for example, the cache intermediate byte-code) on the identified object on the stage 310. If at the stage 312 intermediate code for the identified object found in the cache intermediate byte-code, intermediate byte-code can be extracted and built/compiled to native code on the stage 314. Not necessarily your own code can be cached. At the stage 316 own code can be loaded and executed. If the intermediate bytecode for the identified object is not found in the cache intermediate byte-code, intermediate byte-code can be generated (for example, through reflection emit), intermediate byte-code is generated on the stage 318, intermediate byte-code can be cached on the stage 320, loaded and executed on the stage 322. Will be taken into account that the cache own binary code can be within the Assembly itself, or may be a cache scale machines. This way will be taken into account that the first cache can be a cache intermediate byte-code or a cache source, Assembly, and Vice versa.

An example of a suitable computing environment

To provide context for the various aspects of the subject matter disclosed in the materials of this application, figure 3 and the following discussion is intended to provide a brief General description of a suitable computing environment 510, which can be implemented in different ways implementation. Whereas the object of the invention disclosed in the materials of this application, described in the General context of machine-executable instructions, such as software modules that perform one or more computers or computing devices, specialists in the art will realize that part of the object of the invention disclosed in the materials of this application, can also be implemented in Association with other software modules and/or associations of hardware and software. Usually software modules include procedures, routines, objects, physical artifacts, data structures, etc. that perform specific tasks or implement specific data types. Typically, the functionality of software modules can be merged or divided, as is desirable in different variants of implementation. Computing environment 510 is just one example of a suitable operating environment and has no intention to limit the scope of the functionality of the object of the invention disclosed in the materials of this application.

With reference to figure 3 describes the computer of General purpose in the form of computer 512. Computer 512 may include the device 514 processing, system memory 516 and system bus 518. The device 514 processing can be any of a variety of available processors. As the device 514 processing can also be used for dual microprocessors and other multiprocessor architecture. System memory 516 may include volatile memory 520 and non-volatile memory 522. Non-volatile memory 522 may include permanent memory (ROM, ROM), programmable ROM (PROM, PROM), electrically programmable read-only memory (EPROM) or flash memory. Volatile memory 520 may include random access memory (RAM, RAM)that can act as an external cache memory. System bus 518 connects the system of physical artifacts, including artifacts from system memory to 516 device 514 processing. System bus 518 can be any of several types, including the memory bus, the memory controller, peripheral bus external bus or local bus, and can use any available bus architectures.

Computer 512 typically includes a variety of computer-readable media, such as volatile and non-volatile storage media, removable and non-removable drives. Computer storage media can be implemented by any means or technology to store information, such as machine-readable instructions, data structures, software modules, or other data. Computer storage media include but not as a limitation, random access memory (RAM, RAM), permanent memory (ROM, ROM), electrically erasable and programmable read-only memory (EEPROM EEPROM), flash memory, or other technology memory, CD-ROM, digital multifunctional DVD, or other optical disk storage media, magnetic tape, magnetic tape, magnetic storage disks or other magnetic storage devices or any other media that can be used to store the required information and which can be carried out access the computer 512.

Will be taken into account that figure 3 depicts software that can act as an intermediary between users and computer resources. This software can include the operating system 528, which can be stored on a disk storage device 524 and which can manage and allocate the resources of a computer system 512. Disk storage device 524 can be a hard disk connected to the system bus 518 interface removable memory, such as an interface 526. System application 530 take advantage of resource management operating system 528 through software modules 532 and software data 534 stored either in system memory 516, or on a disk storage device 524. Will be taken into account that the computers can be implemented with different operating systems or combinations of operating systems.

Computer 512 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer(s) 544. The remote computer 544 could be another personal computer, a server, a router, a network PC, peer-to-peer device, or other common host network and typically includes many or all of the elements described above relative to the computer 512, although figure 3 was illustrated only storage device 546 memory. The remote computer(s) 544 can be logically connected via a connection 550 communication. Network interface 548 includes communication networks such as local area network (LAN), wide area network (WAN), but may also include other networks. Connection(I) 550 links indicates reference to the hardware/software used to connect the network interface 548 bus 518. Connection 550 can be internal or external to the computer 512 and may include internal or external technologies such as modems (phone, cable, DSL and wireless) and ISDN adapters, Ethernet cards, etc.

Will be taken into account that shows network connections are examples only and may be used other means of establishing lines of communication between computers. Any ordinary person skilled in the art equipment can be taken into account that the computer 512 or other client devices can be deployed as part of a computer network. In this respect, the object of the invention disclosed in the materials of this application, and can refer to any computer system with any amount of memory and storage devices, and any number of applications and processes on any number of storage devices and memory. Aspects of the object of the invention disclosed in the materials of this application, can be used in an environment with a server computers and client computers that are deployed in a network environment with remote and local storage device. Aspects of the object of the invention disclosed in the materials of this application, can also be applied to Autonomous computing device with the functionality of the programming language, the possibilities of interpretation and implementation.

Figure 4 illustrates an integrated environment 600 (IDE) and the common language environment 602 execution. IDE 600 can allow the user (for example, the developer, programmer, designer, encoder, etc) to develop, to code, compile, test, run, edit, debug and build the program, a set of programs, web sites, web applications and web services in a computer system. Computer programs can include source code (component 610), established in one or more languages source code (for example, Visual Basic, Visual J#, C++, C#, J#, Java Script, APL, COBOL, Pascal, and Eiffel, Haskell, ML, Oberon, Perl, Python, Scheme, Smalltalk, and the like). IDE 600 can provide a development environment own code or can provide the development of managed code that runs on a virtual machine or can provide them together. IDE 600 can provide a development environment managed code that uses the platform .NET Framework. Component 650 intermediate language can be created from a component 610 source code and component 611 own code using the compiler 620 dependent of a source language, and the component 611 own code (for example, Mashinostroenie instructions) is created from the component 650 intermediate language, using the compiler 660 intermediate language (for example, dynamic (JIT) compiler)when the application is running. That is, when IL-the application is running, it is compiled before you can run, suitable machine language for the platform on which it runs, thus, forming a code that is portable to multiple platforms. Alternatively, in other variants of realization of the program can be compiled into native machine language (not shown)that is appropriate for its intended platforms.

The user can create and/or edit the component source code according to well-known technologies of programming software and certain logical and syntactical rules associated with a particular source language through the user interface 640 and editor 651 source code in the IDE 600. Then, the 610 source code can be compiled through the compiler 620 source code, on the basis of what can be created with the view intermediate language for the program, such as Assembly 630. The Assembly 630 may contain a component 650 intermediate language and metadata 642. Before deployment, you can verify the authenticity of the application architecture.

Various techniques described in the materials of this application can be implemented due to hardware or software, or if necessary, a combination of these. Thus, methods and device described in the materials of this application, or certain aspects or parts may take the form of software code (i.e. instructions)concluded in physical media, such as floppy disks, CD-ROMs, hard disks, or any other machine-readable storage medium in which, when the code is loaded and running machine, such as a computer, the machine becomes a device for implementing aspects of the subject matter disclosed in the materials of this application. In the case of the execution of code on a programmable computers, computing device that typically will include the processor, memory media, is read by the controller (including the volatile and non-volatile memory and/or items storage devices), at least one input unit and at least one output device. One or more programs that can use the creation and/or implementation-dependent domain aspects of programming models, for example, through the use of API data, etc. can be implemented in object-oriented programming language of a high level, to communicate with the computer system. However, if necessary, the program can be implemented in Assembly language or machine. In any case, the language can be compiled or interpreted language and can be combined with implementations in hardware.

Meanwhile, as the object of the invention disclosed in the materials of this application, was described in connection with figures, it is clear that in order to perform the same function in different ways can be modifications made.

1. System (100), which caches generated during the execution of code containing: component (120), running in a managed environment execute code on your computer, when this component caches the object (116, 111) in the first cache (109, 118) or in the second cache (109, 118), while the cached object (116, 111) contains the generated during the execution of the code and the generated during execution code is generated dynamically generating code object, while dynamically generating code object does not change the global state and contains metadata (107)identifying whether the object is suitable for caching, while the cached object (116, 111) is derived from the first cache (109, 118) or second cache (109, 118) on subsequent executions cached object (116, 111), missing at least one phase to the code generation, this noise is at least one phase generating code contains the generation of intermediate byte-code or generate your own binary code.

2. The system of claim 1 in which the first cash (109, 118) is a cache that stores intermediate byte-code representing generated during the execution of the code, with noise at least one phase generating code contains the generation of intermediate byte-code to be generated at run time code.

3. The system of claim 1 in which the second cache (109, 118) is a cache that stores your own binary code, while miss at least one phase generating code contains the generation of native binary code to be generated at run time code.

4. The system of claim 1 in which the first cache is a cache of the original Assembly (122), skip at least one phase of generation contains the generation of intermediate byte-code to be generated at run time code or generate your own binary code to be generated at run time code.

5. The system of claim 1 in which the intermediate bytecode generated at run time code retrieved ID consisting of the name associated with dynamically generating code object, at least one argument that is passed in dynamically generating code object and the pointer version for dynamically generating object code.

11. Machine-readable medium of information containing Mashinostroenie the instructions in the fulfillment prescribe the managed computer environment: cache object (116, 111) in the first cache or in the second cache (109, 118), while the cached object contains the generated at run time code generated by generating run-time code object that does not change the global state and contains metadata (107)identifying whether the object is suitable for cached, and the cached object is retrieved on subsequent executions of the object, missing at least one phase code generation in these subsequent executions.

12. Machine-readable medium of information on item 11, containing additional Mashinostroenie the instructions in the fulfillment prescribe computer environment skip generation of intermediate byte-code to the generated during the execution of the code for subsequent executions cached object (111, 116).

13. Machine-readable medium of information on item 11, containing additional Mashinostroenie the instructions in the fulfillment prescribe computer environment skip generation native binary code from intermediate byte-code for the code that is generated at run time, for these subsequent executions cached object (111, 116).

14. Machine-readable medium of information indicated in paragraph 13 that contains additional Mashinostroenie the instructions in the fulfillment prescribe computer environment cache own binary code or intermediate byte-code into the source Assembly (122) the cached object (111, 116).

15. Machine-readable medium of information indicated in paragraph 13 that contains additional Mashinostroenie the instructions in the fulfillment prescribe computer environment: to ensure object (111, 116) specific identifier, using independent execution characteristics of cached objects; and to retrieve a cached object from the first of the cache or the second cache, using as key that particular ID.