A process for generating dynamic type is disclosed. A compiler generated template method including a mark for custom instruction is selected for cloning. dynamic code is injected at the mark for the custom instructions. The template method including the injected dynamic code is compiled.
|
1. A process for generating dynamic type code, comprising:
selecting a compiler generated type-checked template method for cloning having roughly a similar sequence of instructions as the dynamic type code to be generated, the compiler generated type-checked template method including a mark for custom instructions;
injecting dynamic code at the mark for custom instructions in the compiler generated type-checked template method to generate the dynamic type code;
wherein the generated code includes variations to the original code of the template method by the number and types of arguments; and
compiling the generated code.
12. A process for generating dynamic type code, comprising:
emitting original instructions of a selected compiler-generated type-checked template method template having roughly a similar sequence of instructions as the dynamic type code to be generated and having a mark for injecting custom instructions; and
calling a procedure to inject dynamic code in the context of the dynamic type at the mark for custom instructions in the compiler generated type-checked template method to generate the dynamic type code rather than emitting original instructions at the mark, wherein the generated code includes variations to the original code of the template method by the number and types of arguments.
19. A process for generating dynamic type code comprising:
selecting a compiler generated type-checked template method within an application, the type-checked template method having roughly a similar sequence of instructions as the dynamic type code to be generated, the type-checked template method including original instructions and an embedded call to a patching procedure emitting the original instructions;
injecting custom instructions with the patching procedure instead of cloning the embedded call to generate the dynamic type code, wherein the generated code includes variations to the original code of the template method by the number and types of arguments; and
compiling the generated code at runtime.
4. The process of
5. The process of
6. The process of
7. The process of
8. The process of
10. The process of
11. The process of
13. The process of
14. The process of
15. The process of
18. The process of
20. The process of
|
Types and type systems are ubiquitous aspects of computer programming although different languages may use different terminology. A type is a classification of data and assigning a type gives meaning to a sequence of bits. A sequence of bits does not, by itself, provide a distinction between memory addresses, instruction code, integers, floating point numbers, characters, and other purposes for the sequence. Associating a sequence of bits with a type informs computer programs how that sequence of bits should be understood. Other entities, such as objects, modules, communication channels, dependencies, or even types themselves, can become associated with a type.
A type system may be defined as “a tractable syntactic framework for classifying phrases according to the kinds of values they compute.” A type system associates a type with each computed value and includes a set of rules or constraints for the type. A particular type system determines what constitutes a type error. In general, one aim of the type system is to prevent operations expecting a certain kind of value being used with values for which that operation does not make sense. Type systems are often specified as part of programming languages—and built into the interpreters and compilers for them—although they can also be implemented as optional tools.
The process of verifying and enforcing type constraints, often referred to as type checking, may occur either at compile-time or run-time. A programming language uses static typing when type checking is performed during compile-time as opposed to run-time. Static typing is a limited form of program verification, and it allows many type errors to be caught early in the development cycle. Static type checkers evaluate the type information that can be determined at compile time, but are able to verify that the checked conditions hold for further possible executions of the program. Applications created with static languages can be made more efficient, such as faster execution and/or taking reduced memory, by omitting runtime type checks and enabling other optimizations.
A programming language is dynamically typed when the majority of type checking is performed at run-time. Values in dynamic typing have types but variables do not, and a variable can refer to a value of any type. In one example, dynamic languages make excellent scripting languages. Applications created with dynamic languages can be relatively easily extended with new commands and functionality. Dynamic languages are also frequently used for creating Web sites and test harnesses, maintaining server farms, developing various utilities, and performing data transformations.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Emitting code at runtime for dynamic types is currently difficult, time consuming, and error prone. Currently, developers manually write a procedure that outputs a sequence of instructions and arguments in a low level language, which is then compiled into an assembly. Instead of dynamically generating code as described, the disclosure describes a process that reads instructions from a method that has been previously compiled within the assembly and emits those instructions instead. Dynamic code is generated when the previously compiled method is cloned, during which, custom code is injected into the cloned code to alter the behavior of the previously compiled method.
The disclosure is directed to a process for generating dynamic type. A compiler generated template method including a mark for custom instruction is selected for cloning. Dynamic code is injected at the mark for the custom instructions. The template method including the injected dynamic code is compiled.
The accompanying drawings are included to provide a further understanding of embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain principles of embodiments. Other embodiments and many of the intended advantages of embodiments will be readily appreciated, as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.
It is to be understood that features of the various exemplary embodiments described herein may be combined with each other, unless specifically noted otherwise.
The exemplary computer system includes a computing device, such as computing device 100. In a basic configuration, computing device 100 typically includes a processor system having one or more processing units, i.e., processors 102, and memory 104. By way of example, the processing units may include, but are not limited to, two or more processing cores on a chip or two or more processor chips. In some examples, the computing device can also have one or more additional processing or specialized processors (not shown), such as a graphics processor for general-purpose computing on graphics processor units, to perform processing functions offloaded from the processor 102. The memory 104 may be arranged in a hierarchy and may include one or more levels of cache. Depending on the configuration and type of computing device, memory 104 may be volatile (such as random access memory (RAM)), non-volatile (such as read only memory (ROM), flash memory, etc.), or some combination of the two. This basic configuration is illustrated in
Computing device 100 can also have additional features or functionality. For example, computing device 100 may also include additional storage. Such storage may be removable and/or non-removable and can include, but is not limited to, magnetic or optical disks or solid-state memory, or flash storage devices such as removable storage 108 and non-removable storage 110. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any suitable method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Memory 104, removable storage 108 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, universal serial bus (USB) flash drive, flash memory card, or other flash storage devices, or any other storage medium that can be used to store the desired information and that can be accessed by computing device 100. Any such computer storage media may be part of computing device 100.
Computing device 100 often includes one or more input and/or output connections, such as USB connections, display ports, proprietary connections, and others to connect to various devices to provide inputs and outputs to the computing device. Input devices 112 may include devices such as keyboard, pointing device (e.g., mouse), pen, voice input device, touch input device, or other. Output devices 111 may include devices such as a display, speakers, printer, or the like.
Computing device 100 often includes one or more communication connections 114 that allow computing device 100 to communicate with other computers/applications 115. Example communication connections can include, but are not limited to, an Ethernet interface, a wireless interface, a bus interface, a storage area network interface, a proprietary interface. The communication connections can be used to couple the computing device 100 to a computer network, which can be classified according to a wide variety of characteristics such as topology, connection method, and scale. A network is a collection of computing devices and possibly other devices interconnected by communications channels that facilitate communications and allows sharing of resources and information among interconnected devices. Examples of computer networks include a local area network, a wide area network, the Internet, or other network.
The computing device 100 can be configured to run an operating system software program and one or more computer applications, which make up a system platform. A computer application configured to execute on the computing device 100 includes at least one process (or task), which is an executing program. Each process provides the resources to execute the program. One or more threads run in the context of the process. A thread is the basic unit to which an operating system allocates time in the processor 102. The thread is the entity within a process that can be scheduled for execution. Threads of a process can share its virtual address space and system resources. Each thread can include exception handlers, a scheduling priority, thread local storage, a thread identifier, and a thread context, or thread state, until the thread is scheduled. A thread context includes the thread's set of machine registers, the kernel stack, a thread environmental block, and a user stack in the address space of the process corresponding with the thread.
An operation may execute in a thread separate from the main application thread. When an application calls methods to perform an operation, the application can continue executing on its thread while the method performs its task. Concurrent programming for shared-memory multiprocessors can include the ability for multiple threads to access the same data. The shared-memory model is the most commonly deployed method of multithread communication. Multiple threads execute on multiple processors, multiple processor cores, multiple logical nodes in a single processor core, and/or other classes of parallelism that are attached to a memory shared between the processors.
In one example, the computing device 100 includes a software component referred to as a managed environment. The managed environment can be included as part of the operating system or can be included later as a software download. Typically, the managed environment includes pre-coded solutions to common programming problems to aid software developers to create applications, such as software programs, to run in the managed environment. Examples of managed environments can include an application framework or platform available under the trade designation .NET Framework from Microsoft Corporation of Redmond, Wash. U.S.A, and Java now from Oracle Corporation of Redwood City, Calif., U.S.A., as well as others and can include web application frameworks often designed to support the development of dynamic websites, web applications and web services.
Typically, each program written in a compatible language will be compiled into a second platform-neutral language 130—with corresponding language-specific compilers 134, 136, 138, respectively—within a Common Language Infrastructure (CLI) 140. In general, the second platform-neutral language is referred to as an intermediate language, or IL. In the case of the .NET Framework, the second platform-neutral language 130 is often referred to as the Common Intermediate Language (CIL), and the language compilers 134, 136, and 138 emit the CIL. A development tool, such as an IL disassembler, can be used to inspect the second platform-neutral language. The program in the second platform-neutral language 130 is provided to a runtime compiler 142, such as one available under the trade designation Microsoft Common Language Runtime (CLR) in the .NET Framework, that compiles the program in the second platform-neutral language 130 into a platform-specific machine-readable code 144 that is executed on the current platform or computing device. Other managed environments or other implementations could facilitate the execution of the second platform-neutral language 130 other than with the runtime compiler 142 such as with interpretation or another method, or with a combination of the two or more methods.
The example of a managed environment 120 can also include a dynamic language runtime, in one example, as part of the runtime compiler 142. The dynamic language runtime (DLR) is a runtime environment that adds a set of services for dynamic languages to the common language runtime (CLR). The DLR provides additional support to develop dynamic languages to run on the .NET Framework and to add dynamic features to statically typed languages. The DLR also enables a system of dynamic languages to run on and have interoperability in the .NET Framework. The DLR introduces dynamic objects to C# and Visual Basic in a development tool such as one available under the trade designation Visual Studio 2010 from Microsoft Corp. to support dynamic behavior in these languages and enable their interoperation with dynamic languages. The DLR also helps developers create libraries that support dynamic operations. For example, in a library that uses Extensible Markup Language (XML) or JavaScript Object Notation (JSON) objects as well as others, the objects can appear as dynamic objects to languages that use the DLR. This provides library users with an ability to write syntactically simpler and more natural code for operating with objects and accessing object members.
Emitting code for dynamic types, however, is currently very difficult, error prone and time consuming. Currently, developers manually write a procedure that outputs a sequence of instructions and arguments in IL, instead of a high level language such as C#, which are then compiled into an assembly. This process does not take advantage of a compiler, and so it is equivalent to writing code in assembly. As a result, it is very difficult to emit complex functions at runtime using dynamic code generation, and even harder to make changes to this code once the emitting procedure has been developed. Thus, while dynamic types provide advantages and/or alternatives to static types, generating dynamic code remains cumbersome and susceptible to developer error.
A method is generally understood to be a subroutine associated with a class. A subroutine, also referred to as a procedure, function, routine, method, or subprogram, is a portion of code that can be used in a larger program such as to perform a specific task. Methods can be relatively independent of the larger program. Methods define the behavior to be exhibited by instances of the associated class at run time of the program. A class is a construct that is used as a blueprint to create instances of itself, which is often referred to as class instances, class objects, instance objects or simply objects. A class defines constituent members that enable these class instances to have state and behavior. At run time, methods have access to data stored in an instance of the class they are associated with and are able to control the state of the instance. The association between class and method is called binding, and a method associated with a class is often referred to as being “bound” to the class. Methods can be bound to a class at compile time, which is often referred to as static binding, or to an object at runtime, which is often referred to as dynamic binding.
Referring to
The template method also includes a mark in the original instructions to indicate a location for customized instructions at 302. Dynamic code for the particular circumstance of the method is injected into the original code at the mark for the customized instructions at 304. For example, rather than emitting the original instructions at the mark, a procedure can be called to inject the dynamic code. The original code from the template method as well as the injected dynamic code is compiled at 306.
The process 300 selects and clones the template method at 302. In one example, a template method is defined, or created, and is compiled into the application. An application can include several different template methods or several similar template methods that are to be configured for different circumstance. The template method can be particularly created for the application, but examples are contemplated where the template method selected from a repository of generic template methods. The selected template method includes bytecode to be copied. Bytecode is a term for instruction sets designed for efficient execution by a software interpreter as well as being suitable for further compilation into machine code.
A cloning procedure, such as one available as part of the managed environment or the development tool, is enlisted to begin cloning the original instructions of the selected template method. The original instructions, which were compiler generated, are extracted from the template method. In the .NET Framework, the cloning procedure converts the instructions into a stream of IL OpCodes (operation codes) and CLR objects that can then be emitted using the Reflection.Emit application programming interface (API). The cloning procedure can also keeps track of data such as labels for break statements, as well as try/catch statements, and the like. This provides for the cloning procedure to emit dynamic methods without having to keep track of low-level instructions directly and allows the dynamic methods to take advantage of the compiler-produced byte code.
The template method includes a mark in the original instructions to indicate the location for customized instructions at 302. Custom instructions are injected at the mark instead of the original code such as by calling a patching procedure. When the cloning procedure is emitting code, each instruction is checked to determine whether it has been marked for a patch. If the instruction has been marked for a patch, then instead of emitting the original instruction, the cloning procedure calls the patching procedure. The patching procedure then manually emits a small block of custom code that depends on the context of the dynamic type.
In one example of injecting dynamic code at selected points in the template method at 304, the template method includes embedded calls to a static generic method in a class called “Patcher”. As an example, the following statement:
Patcher.PatchWithNoReturnValue<CallBaseMethodPatch>( );
can be used to patch the template with dynamic code that calls a base class method at the location of the template method where the behavior is to be altered.
As the cloning procedure iterates over the bytecode of the template method, it looks for instructions that call static generic methods on the patcher class. One advantageous reason to use static generic methods to mark locations for the custom code is because the above statement compiles into a single instruction in IL. When the cloning procedure finds calls to the Patcher class, it inspects the generic arguments of the method call to determine the name of the Patcher class to call. In the example above, this patch is called CallBaseMethodPatch. The cloning procedure then instantiates an instance of the patch and calls it, passing it the context of the cloning procedure. The patch is then able to inject dynamic code at a particular point in the IL stream that is independent of what the compiled template produced.
The process 300 includes several advantages over other code generating solutions, and a few of the advantages are set out here. Without the template method, a developer manually generates the dynamic code for an entire method in order to get the desired customization. In process 300, however, the developer can split the code generation up across multiple patches, which can be re-used in multiple templates. Instead of having to procedurally generate the entire method, the compiler generates the majority of the template method and augments it with custom patches. This eliminates much of the complexity from the process of generating dynamic methods and makes for easy to change to the template and thus the generated types. The patches can be easily tested because they produce small, targeted blocks of code that can be verified independent of a template.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
Patent | Priority | Assignee | Title |
9361288, | Aug 09 2013 | GOOGLE LLC | Processing templates using separate template processing instructions |
Patent | Priority | Assignee | Title |
5339430, | Jul 01 1992 | Telefonaktiebolaget L M Ericsson | System for dynamic run-time binding of software modules in a computer system |
6044224, | Jun 26 1996 | Oracle America, Inc | Mechanism for dynamically associating a service dependent representation with objects at run time |
6072953, | Sep 30 1997 | International Business Machines Corporation | Apparatus and method for dynamically modifying class files during loading for execution |
6282701, | Jul 31 1997 | IDENTIFY SOFTWARE LTD | System and method for monitoring and analyzing the execution of computer programs |
6351843, | Aug 31 1998 | International Business Machines Corporation | Dynamically inserting a function into an application executable at runtime |
6779187, | Apr 08 1999 | Hewlett Packard Enterprise Development LP | Method and system for dynamic interception of function calls to dynamic link libraries into a windowed operating system |
6898788, | Oct 30 1998 | WSOU Investments, LLC | System for modifying the functionality of compiled computer code at run-time |
6957422, | Oct 02 1998 | Microsoft Technology Licensing, LLC | Dynamic classification of sections of software |
6968540, | Oct 25 2000 | RIVERBED TECHNOLOGY LLC | Software instrumentation method and apparatus |
7111279, | Oct 30 2002 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Intercepting calls to common dialog functions |
7117484, | Apr 16 2002 | LinkedIn Corporation | Recursive use of model based test generation for middleware validation |
7293260, | Sep 26 2003 | Oracle America, Inc | Configuring methods that are likely to be executed for instrument-based profiling at application run-time |
7353507, | Oct 30 2002 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Intercepting function cells |
7370360, | May 13 2002 | PALO ALTO NETWORKS, INC | Computer immune system and method for detecting unwanted code in a P-code or partially compiled native-code program executing within a virtual machine |
7437715, | Apr 09 2002 | GOOGLE LLC | System and method for generating a set of robot commands based on user entry events in a user interface |
7461385, | May 06 2003 | QAD Corporation | Method for establishing a new user interface via an intermingled user interface |
7689985, | Mar 04 2005 | Microsoft Technology Licensing, LLC | Versioning support for drivers frameworks |
7752607, | Oct 13 2005 | SAP SE | System and method for testing business process configurations |
7788647, | Jul 26 2001 | iRise | Systems and methods for collaborative programming of simulations of computer programs |
7873872, | Jul 10 2001 | VERSATA DEVELOPMENT GROUP, INC | System and method for remotely debugging application programs |
7873945, | Jun 29 2007 | Microsoft Technology Licensing, LLC | Automatically generating test cases for binary code |
7900258, | May 13 2002 | PALO ALTO NETWORKS, INC | Computer immune system and method for detecting unwanted code in a P-code or partially compiled native-code program executing within a virtual machine |
7926042, | Oct 31 2005 | VALTRUS INNOVATIONS LIMITED | System and method for dynamic instrumentation |
7930683, | Mar 31 2006 | SAP SE | Test automation method for software programs |
7971090, | Sep 26 2007 | International Business Machines Corporation | Method of testing server side objects |
7984429, | Oct 02 1998 | Microsoft Technology Licensing, LLC | Tools and techniques for instrumenting interfaces of units of a software program |
8046752, | Nov 25 2002 | Microsoft Technology Licensing, LLC | Dynamic prefetching of hot data streams |
8209669, | Apr 20 2007 | SAP SE | System and method for supporting software |
8225293, | Feb 13 2003 | Accurate Technologies Inc. | Method for supporting calibration parameters in an ECU |
8234633, | Jan 09 2008 | SAP SE | Incident simulation support environment and business objects associated with the incident |
8245194, | Oct 18 2006 | International Business Machines Corporation | Automatically generating unit test cases which can reproduce runtime problems |
8261244, | Jun 02 2006 | Microsoft Technology Licensing, LLC | Arbitrary runtime function call tracing |
8407678, | Aug 27 2008 | Red Hat, Inc. | Method of array interception using data-flow analysis |
8627296, | Sep 15 2010 | GOOGLE LLC | Unified unit and integration test with automatic mock creation |
8635582, | Jan 22 2010 | GLOBALFOUNDRIES U S INC | Navigating analytical tools using layout software |
8707265, | Mar 31 2006 | SAP SE | Test automation method for software programs |
8806437, | Jun 29 2011 | International Business Machines Corporation | Automated testing process |
8954929, | Mar 29 2010 | Microsoft Technology Licensing, LLC | Automatically redirecting method calls for unit testing |
20020049963, | |||
20040163077, | |||
20040194063, | |||
20060282460, | |||
20070157156, | |||
20070168998, | |||
20070261044, | |||
20080046868, | |||
20080082959, | |||
20080301635, | |||
20090007073, | |||
20090064113, | |||
20090144714, | |||
20100218172, | |||
20110239194, | |||
20120084754, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Dec 09 2011 | BRAUDE, MICHAEL J | Microsoft Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027381 | /0269 | |
Dec 14 2011 | Microsoft Technology Licensing, LLC | (assignment on the face of the patent) | / | |||
Oct 14 2014 | Microsoft Corporation | Microsoft Technology Licensing, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 034544 | /0541 |
Date | Maintenance Fee Events |
Mar 07 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Mar 08 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Sep 22 2018 | 4 years fee payment window open |
Mar 22 2019 | 6 months grace period start (w surcharge) |
Sep 22 2019 | patent expiry (for year 4) |
Sep 22 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
Sep 22 2022 | 8 years fee payment window open |
Mar 22 2023 | 6 months grace period start (w surcharge) |
Sep 22 2023 | patent expiry (for year 8) |
Sep 22 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
Sep 22 2026 | 12 years fee payment window open |
Mar 22 2027 | 6 months grace period start (w surcharge) |
Sep 22 2027 | patent expiry (for year 12) |
Sep 22 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |