HK1182484B - Profile guided jit code generation - Google Patents

Description

Profile-oriented JIT code generation

Technical Field

This application relates to JIT code generation and, more particularly, to profile-directed JIT code generation.

Background

Many types of programming languages exist. One form of programming language is a scripting language. A scripting language is a programming language capable of enabling control of one or more applications. The "script" or program generated from the scripting language may be written in the same language as the language of the associated application or a different language. While applications are typically compiled first into native machine code, scripts are often interpreted from source code.

Another form of programming language is the dynamic programming language. A dynamic programming language is a programming language that performs some other (not dynamic) programming language behavior during runtime that may be performed during compilation. Such behavior may include extending the program by adding new code, extending objects, and defining and/or modifying the type system. Many scripting programming languages are also dynamic programming languages.

A Web browser is an application for rendering Web pages for display. Scripts are frequently run on web pages to dynamically change their content. Client-side scripts generally refer to scripts that are executed by a web browser on the client-side rather than on the server-side on a web server. Client-side scripts may make a web page more responsive to user input by avoiding one or more round-trip communications with the web server.

Scripts written in dynamic programming languages are difficult to execute efficiently. For example, JavaScript (developed by Mozilla corporation of mountain View, Calif.) is a very flexible example dynamic programming language used in scripts. In many JavaScript programs, only a portion of the JavaScript code is executed, while an even smaller portion of the JavaScript code is run at program startup. In this manner, parsing of the entire codebase unnecessarily delays initiation of execution. Furthermore, most code written in JavaScript in practice does not take full advantage of the flexibility of the JavaScript language. However, machine code generated by JavaScript compilers is generated to handle a large number of possibilities correctly at runtime, which results in inefficient execution.

Disclosure of Invention

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.

Methods, systems, and computer program products are provided for executing scripts and other programs written in dynamic languages in an efficient manner. The script may be received by the runtime engine for execution as part of a web page or other document. The runtime engine may use an interpreter (interpreter) to execute the script. Profile information about the script is collected by the interpreter during execution of the script. The profile information may be used to determine which portions of the script may be more efficiently executed by compiling the portions using a compiler and executing the resulting machine code, rather than interpreting the portions of the script. Thus, some portions of the script may be executed using an interpreter, while other portions of the script may be compiled and executed using a compiler. Further, the compiled portions of the script may be stored for later use (if these portions of the script are subsequently executed again). Further, the startup portion of the script may be determined and indicated in the profile information so that the startup portion may be processed first by the runtime engine before the script is run.

In an example method implementation, source code encoded in a dynamic language is received for execution. The source code is parsed to generate parsed source code. The parsed source code is converted into bytecode. The bytecode is interpreted using an interpreter. Profile information about the bytecode is generated. Profile information is stored.

Further, the profile information may be analyzed to determine a condition associated with the received portion of the bytecode. The bytecode portion can be just-in-time (JIT) compiled into a compiled bytecode portion as a result of the determined condition. The compiled portions of bytecode may be stored.

In addition, the bytecode portion can then be received again in the bytecode at the interpreter. Compiled bytecode portions corresponding to the received bytecode portions can be located in storage. At least one condition check may be performed on the compiled portion of bytecode located in storage. If at least one of the condition checks passes, the compiled bytecode portion may be executed instead of interpreting the received bytecode portion.

In an example system implementation, a runtime engine is provided. The runtime engine includes a parser, a bytecode generator, an execution controller, an interpreter, a JIT compiler, and a profile generator. The parser receives source code encoded in a dynamic language and parses the source code to generate parsed source code. The bytecode generator converts the parsed source code into bytecode. The interpreter is configured to interpret the bytecode when enabled by the execution controller. The JIT compiler is configured to compile bytecode when enabled by the execution controller. The profile generator generates profile information from the bytecode and stores the profile information. The execution controller enables the interpreter or JIT compiler to perform their respective functions based on the profile information.

Computer program products for generating profile information from source code and enabling efficient execution of the source code based on the profile information, and for enabling additional embodiments, are also described herein.

Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It should be noted that the present invention is not limited to the particular embodiments described herein. These examples are presented herein for illustrative purposes only. Other embodiments will be apparent to persons skilled in the relevant art based on the description contained herein.

Brief Description of Drawings

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention.

FIG. 1 shows a block diagram of a computing device including a browser application configured to render pages from a received document, according to an example embodiment.

FIG. 2 shows a block diagram of a browser application interacting with a runtime engine configured to execute a script and generate profile information about the script, according to an example embodiment.

FIG. 3 shows a block diagram of a runtime engine configured to interpret portions of a script and execute compiled portions of the script based on profile information generated from the script, according to an example embodiment.

FIG. 4 shows a flowchart of a process for providing profile information for executing a script and generating the script, according to an example embodiment.

FIG. 5 shows a block diagram of a profile generator according to an example embodiment.

FIG. 6 shows a flowchart providing a process for indicating the startup portion of a script in profile information, according to an example embodiment.

FIG. 7 shows a flowchart of a process for providing profile information for generating a script library, according to an example embodiment.

FIG. 8 shows a flowchart of a process for providing portions for compiling a script based on profile information for the script, according to an example embodiment.

FIG. 9 illustrates a block diagram of an execution controller including a code optimization module, according to an example embodiment.

FIG. 10 shows a flowchart providing a process for using profile information to improve script launching, according to an example embodiment.

Fig. 11 illustrates a block diagram of an execution controller configured for execution of stored compiled bytecode, according to an example embodiment.

FIG. 12 shows a flowchart providing a process for executing a script, according to an example embodiment.

FIG. 13 shows a block diagram of the runtime engine of FIG. 3 in which stored compiled bytecode is executed for use in portions of a script, according to an example embodiment.

FIG. 14 shows a flowchart of a process for providing situational checking for tracking compiled bytecode, according to an example embodiment.

FIG. 15 illustrates a block diagram of an example computer that can be used to implement embodiments of the invention.

The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description

I. Introduction to the design reside in

This specification discloses one or more embodiments that include various features of the invention. The disclosed embodiments are merely illustrative of the invention. The scope of the invention is not limited to the disclosed embodiments. The invention is defined by the appended claims.

References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

Various exemplary embodiments of the present invention are described below. It should be understood that any section/sub-section headings provided herein are not intended to be limiting. Embodiments are described in this document, and any type of embodiment can be included under any section/sub-section.

Example embodiments

Dynamic languages are frequently used for code in scripts to control web browsers. Examples of such dynamic languages include JavaScript (developed by Mozilla corporation of mountain dimension, california), VBScript (developed by microsoft corporation of redmond, washington), AJAX (different periods of JavaScript and XML), Python (developed by Python software corporation, terawa, usa), Perl (which is an open source programming language developed by LarryWall), and so forth. The scripts are typically parsed and interpreted or compiled on-demand at the client side (e.g., as a result of a web page being downloaded by a web browser). For many scripts, only a portion of the script source code is executed, while an even smaller portion of the source code is run at program start-up. For example, for many web pages, only about 15% -20% of the code loaded for the user is actually executed. As such, the parsing of the entire source code may unnecessarily delay the initiation of execution. Furthermore, many source codes do not take full advantage of the flexibility of scripting languages. However, machine code generated by a script compiler is generated to handle a large number of possibilities correctly at runtime, which results in inefficient execution.

For example, dynamic languages enable generation of scripts that: the script has different and varying content during runtime depending on user input, environmental conditions (such as time of day), or other variables. Objects represented in such dynamic languages may have varying types, objects may change in shape (e.g., may have attributes dynamically added), expression values may change, and/or other code factors may change dynamically during runtime. Thus, scripts encoded in dynamic languages are typically interpreted line-by-line, rather than being pre-compiled and then executed, because the complete script content is not known during compile time. Because of these complexities, scripts encoded in dynamic languages are often inefficiently executed, which is undesirable to users to whom the output of the script (e.g., user interface, etc.) is to be displayed.

In embodiments, scripts are executed more efficiently such that some portions of the script may be interpreted while other portions of the script are compiled and executed as machine code. The interpreter can start executing script code relatively quickly (low start-up cost). However, interpreted script code executes much slower than machine code. While machine code can be executed faster than an interpreter can execute, compiling script code into machine code prior to execution of the machine code can be time consuming (high start-up cost). Thus, in some cases, embodiments leverage properties of scripts to interpret portions of the scripts, while in other cases, portions of the scripts are compiled on-the-fly into machine code for execution. For example, less frequently used portions of the script may be interpreted (in progress), while more frequently used portions of the script may be compiled and executed. Further, the compiled script code may optionally be stored to save time during further execution of the script. Thus, embodiments enable scripts to be executed more quickly than in the prior art.

For example, in one embodiment, profile data/information (profile information) is collected about patterns (patterns) that appear in the script when the script is executed. Examples of such patterns include code that is executed relatively frequently ("hotspots"). Once a sufficient amount of profile data is collected about the script, this data can be used by the compiler to generate better optimized machine code that is specific to the execution mode recorded in the profile data. The processor executing the script may be switched to the optimized code path on demand so that execution of the script is accelerated. The profile data may be saved in persistent storage and accessed during subsequent execution of the script. Further, the profile data may indicate portions of the script that were executed during startup of the script. This profile data may be used to shorten the length of time for the startup phase of the script (which may include parsing the script code and generating bytecode from the script) by first interpreting or compiling the startup portion of the script.

Such embodiments may be implemented in various environments. For example, FIG. 1 shows a block diagram of a web browsing environment 100, according to an example embodiment. As shown in FIG. 1, environment 100 includes a computing device 102, a server 104, and a network 106. As shown in fig. 1, computing device 102 includes a browser application 108. Environment 100 is described below. The environment 100 is provided for illustrative purposes and is not intended to be limiting. Embodiments may be implemented in further environments as will be apparent to those of skill in the art from the technology herein.

Computing device 102 may be any type of stationary or mobile computing device, including a desktop computer (e.g., a personal computer, etc.), a mobile computer or computing device (e.g.,equipment, RIMDevices, Personal Digital Assistants (PDAs), laptop computers, notebook computers, tablet computers (e.g., apple iPad)^TM) Netbook, etc.), mobile phones (e.g., cellular phones, smart phones, such as apple iphone, google android^TMMobile phone, MicrosoftCell phones, etc.) or other types of mobile devices. The server 104 may be implemented in one or more computer systems comprising one or more servers, which may be any type of computing device described herein or otherwise known computing device capable of implementing the respective functionality described herein.

Computing device 102 and server 104 are communicatively coupled by network 106. Network 106 may include one or more communication links and/or communication networks, such as a PAN (personal area network), a LAN (local area network), a WAN (wide area network), or a combination of networks, such as the Internet. The computing device 102 and the server may be communicatively coupled to the network 106 using various links including wired and/or wireless links, such as IEEE802.11 Wireless Local Area Network (WLAN) wireless links, worldwide interoperability for microwave access (Wi-MAX) links, cellular network links, wireless Personal Area Network (PAN) links (e.g., Bluetooth)^TMLink), an ethernet link, a USB link, etc.

The single computing device 102 is shown in FIG. 1 for illustrative purposes. However, any number of computing devices 102 may be present in the environment 100, including tens, hundreds, thousands, and even larger numbers of computing devices 102. Each computing device may operate one or more respective browser applications.

The browser application 108 is a program executing/operating in the computing device 102. The browser application 108 enables network information resources to be retrieved, presented, and traversed. A network address, such as a Uniform Resource Identifier (URI), may be used to retrieve an information resource or object through the browser application 108. Examples of information resources include web pages, images, videos, and other forms of content. Hyperlinks present in information resources enable users to easily navigate their browsers to related resources. An example of a browser application 108 includes the Internet developed by Microsoft corporation of Redmond, WashingtonMozilla, developed by Mozilla corporation of mountain vitamin, CaliforniaDeveloped by Apple Inc. of Coopertino, CalifAnd developed by Chrome corporation of mountain View, Calif

As shown in FIG. 1, browser application 108 may retrieve document 112 from server 104 over network 106. The document 112 may be a web document that includes code for a markup language, such as hypertext markup language (HTML), dynamic HTML (dhtml), extensible HTML (xhtml), extensible markup language (XML), and so forth. As shown in FIG. 1, the document 112 includes a DOM (document object model) object 114 and one or more scripts 116. DOM object 114 includes one or more objects represented in document 112 according to a DOM specification, which is a cross-platform and language independent specification for representing and interacting with the objects. DOM objects 114 can include objects that are included directly in document 112, and/or objects that are referenced by document 112 and retrieved separately from server 104 or other servers. The script 116 includes code formatted according to a dynamic language (e.g., JavaScript, VBScript, AJAX, Python, Perl, etc.) that enables changes to be made to the DOM object 114, including changes based on factors such as user input, environmental conditions (e.g., time of day, or other variables). The code of the script 116 can access and modify the objects of the DOM object 114 on the fly without returning to the server 104.

As shown in fig. 1, browser application 108 receives (e.g., loads) document 112. The browser application 108 includes a browser engine (e.g., a layout engine or a rendering engine) that formats information of the document 112 and displays the formatted information. For example, as shown in FIG. 1, the browser application 108 may generate the page 118 based on the document 112 displayed by the display of the computing device 102.

The browser application 108 may be configured to execute one or more scripts 116, the one or more scripts 116 being embedded in the document 112 or separate from the document 112 but associated with the document 112. For example, FIG. 2 illustrates a block diagram of a browser application 108 interacting with a runtime engine 202, according to an example embodiment. The runtime engine 202 is configured to execute scripts of the browser application 108, such as the scripts 116 of FIG. 1. In an embodiment, the runtime engine 202 may be separate from the browser application 108 as shown in FIG. 2, such as a plug-in or add-in module to the browser application 108. In another embodiment, the runtime engine 202 may be integrated in the browser application 108.

As shown in FIG. 1, browser application 108 receives document code 206, which is code in document 112 and/or code referenced by document 112. The browser engine of browser application 108 executes document code 206. If the browser application 108 encounters a script of the document 112, the browser application 108 can provide script source code 208 of the script to the runtime engine 202 for execution. The runtime engine 202 is directed to scripts programmed in a dynamic programming language (or "dynamic language"). Thus, the runtime engine 202 can implement further features of dynamic typing and dynamic language. In an embodiment, the runtime engine 202 may be implemented as a Virtual Machine (VM). Using dynamically typed languages (such as JavaScript, Python, etc.), it is generally not known what types of various items of data can be assumed until the program code is actually executed. For example, it may not be known whether a dynamically typed variable is an integer, floating point, or string until the code is actually executed by the runtime engine. Runtime engine 200 is configured to handle this dynamic capability of the dynamic language when executing source code 208.

The runtime engine 202 may generate executable code 210 based on executing the script source code 208, the executable code being executed (e.g., by one or more processors). The browser application 108 may generate presentation information 212 based on the execution of the document code 206 and based on the executable code 210.

As shown in FIG. 2, the runtime engine 202 includes a profile generator 204. Profile generator 204 is configured to analyze script source code 208 to collect statistics and further information about script source code 208. For example, the profile generator 204 may determine portions of the script source code 208 that are frequently executed, startup portions of the script source code 208, and/or further information about the script source code 208. The profile generator 204 may maintain the collected information as profile information. As described herein, the runtime engine 202 may use the collected profile information to more efficiently execute the script source code 208.

Various exemplary embodiments of the runtime engine 202 and further embodiments for improving script execution performance are described below. For example, the following subsections describe example embodiments of runtime engine architecture and processes for operating a runtime engine. Still further sub-sections below describe example embodiments for collecting source code profile information, for optimizing source code portions based on the collected profile information, and for executing the optimized source code.

A. Example embodiments of a runtime Engine

According to an example embodiment, a runtime engine (such as runtime engine 202 of FIG. 2) is configured to collect profile information about scripts that are executed and use the profile information to improve script execution performance. Such a runtime engine may be configured in a variety of ways in various embodiments. For example, FIG. 3 illustrates a block diagram of a runtime engine 300, according to an example embodiment. As shown in fig. 3, runtime engine 300 includes an engine interface 302, a parser 304, a bytecode generator 306, an execution controller 308, an interpreter 310, a JIT (just-in-time) compiler 312, storage 314, a machine code executor 316, and a scripting library 318. Runtime engine 300 is described below.

As shown in fig. 3, the engine interface 302 receives the script source code 208. The engine interface 302 is optionally present, and in some embodiments, the parser 304 may be configured to interface with the runtime engine 300 without the engine interface 302 being present. When present, engine interface 302 is a communication interface that provides one or more methods for interfacing a host with runtime engine 300. In an example embodiment, the engine interface 302 may be implemented according to IActivScript developed by Microsoft corporation of Redmond, Washington. As shown in fig. 3, engine interface 302 provides source code 208 to parser 304.

Parser 304 receives and parses source code 208. For example, parser 304 may perform token generation or lexical analysis of source code 208 such that source code 208 is formatted into symbols or tokens. Parser 304 may perform an error check on the token to determine whether an allowable expression is formed, a syntactic error does not exist, etc. As shown in fig. 3, parser 304 outputs the parsed source code as parsed source code 322. Parsed source code 322 may have any suitable form, including being generated by parser 304 as AST (abstract syntax tree) code that includes a tree representation of the abstract syntax structure of source code 208, as known to those skilled in the art.

As shown in fig. 3, bytecode generator 306 receives parsed source code 322. Bytecode generator 306 is configured to convert parsed source code 322 into bytecode, which includes an instruction set configured for efficient execution by an interpreter and for further compilation into machine code. For example, the generated bytecode may represent the parsed source code 322 as a numeric code and corresponding optional parameters. As shown in fig. 3, bytecode generator 306 outputs the generated bytecode as bytecode 324. Bytecode 324 may have any suitable form, including p-code (portable code) generated by bytecode generator 306 as known to those skilled in the art.

As shown in fig. 3, execution controller 308, interpreter 310, and JIT compiler 312 each receive bytecode 324. Further, as shown in fig. 3, the interpreter 310 includes a profile generator 204. Profile generator 204 is configured to analyze bytecode 324 to collect statistics and further information about source code 208. The profile generator 204 generates profile information 320, which includes the collected information and is stored in the storage 314.

As shown in fig. 3, the execution controller 308 accesses the profile information 320 and is communicatively coupled to the interpreter 310 and the JIT compiler 312. Based on bytecode 324 and profile information 320, execution controller 308 may enable one of interpreter 310 and JIT compiler 312 to operate on bytecode 324. The interpreter 310 is configured to interpret the bytecode 324 when enabled by a control signal 326 received from the execution controller 308. JIT compiler 312 is configured to compile bytecode 324 when enabled by control signals 328 received from execution controller 312. For example, during a first execution of source code 208, profile information 320 may not yet exist. In this case, the execution controller 308 may enable the interpreter 310 to interpret the bytecode 324 and generate the profile information 320. During subsequent execution of source code 208 (e.g., later during the same first execution of source code 208, and/or during a subsequent execution of source code 208), execution controller 308 may enable interpreter 310 to interpret portions of source code 208 and may enable JIT compiler 312 to compile other portions of source code 208, in accordance with profile information 320.

When interpreter 310 is enabled by interpreter control signal 326, interpreter 310 interprets and executes bytecode 324. For example, the interpreter 310 may be implemented as a JavaScript interpreter, a VBScript interpreter, a Python interpreter, or an interpreter for another dynamic language mentioned elsewhere herein or otherwise known. In this manner, source code 208 may be executed at least in part by the operation of interpreter 310.

When JIT compiler 312 is enabled by compiler control signal 328, JIT compiler 312 compiles bytecode 324. For example, the JIT compiler 312 may be implemented as a JavaScript compiler, VBScript compiler, Python compiler, or a compiler for another dynamic language mentioned elsewhere herein or otherwise known. The JIT compiler 312 is referred to as a "just-in-time" compiler because, due to the need for compiled bytecode (e.g., to be executed urgently), certain bytecode portions may be compiled by the JIT compiler 312 rather than pre-compiling the complete bytecode 324 before execution. As shown in fig. 3, JIT compiler 312 generates compiled bytecode 330, which is in the form of machine-executable code or instructions. The compiled bytecode 330 is received by a machine code executor 316 (e.g., one or more processors) that executes the compiled bytecode 330. In this manner, source code 208 may be executed in part by the operations of JIT compiler 312 and machine code execution 316. Further, as shown in fig. 3, compiled bytecode 330 can be stored in storage 314 as compiled bytecode 332 for access during subsequent execution of source code 208 by runtime engine 300.

The runtime engine 300 of FIG. 3 may operate in various ways to perform its functions. For example, FIG. 4 shows a flowchart 400 of a process for providing profile information for executing a script and generating the script, according to an example embodiment. Flowchart 400 is described below with reference to fig. 3. Other structural and operational embodiments will be apparent to those skilled in the relevant arts based on the following discussion of flowchart 400.

The flowchart 400 begins at step 402. At step 402, source code encoded in a dynamic language is parsed to generate parsed source code. For example, as shown in fig. 3, the parser 304 receives (optionally through the engine interface 302) the script source code 208. As described above, parser 304 is configured to parse source code 208 into parsed source code 322.

At step 404, the parsed source code is converted into bytecode. For example, as shown in fig. 3, bytecode generator 306 receives parsed source code 322. As described above, bytecode generator 306 is configured to convert parsed source code 322 into bytecode 324. Note that in various embodiments, steps 402 and 404 may be considered together as a process for generating bytecode 324 from received source code 208, and may be performed in other ways.

At step 406, the bytecode is interpreted using an interpreter. For example, as shown in fig. 3, interpreter 310 receives bytecode 324. As described above, the interpreter 310 is configured to interpret the bytecode 324. For example, interpreter 310 may interpret bytecode 324 by: the bytecode 324 is translated into an efficient intermediate code representation and executed, or the bytecode 324 is interpreted in another way to enable program execution.

At step 408, profile information about the bytecode is generated. For example, as shown in FIG. 3, the profile generator 204 receives the bytecode 324. Profile generator 204 is configured to analyze bytecode 324 to collect statistics and further information about source code 208. The profile generator 204 generates profile information 320, which includes the collected information.

At step 410, profile information is stored. For example, as shown in FIG. 3, the profile generator 204 stores profile information 320 in the storage 314. Note that storage 314 may include one or more of any type of storage mechanism, including a magnetic disk (e.g., in a hard disk drive), an optical disk (e.g., in an optical disk drive), a magnetic tape (e.g., in a tape drive), a memory device such as a RAM (random access memory) device, and/or any other suitable type of storage medium.

Note that when implemented as code executing in one or more processors, runtime engine 300 and/or process 400 can be distributed in any manner among one or more program execution threads. For example, in one example, the parser 304, bytecode generator 306, execution controller 308, and interpreter 310 may operate in a first thread (e.g., a foreground or UI thread), while the JIT compiler 312 may operate in a second thread (e.g., a background thread). In other embodiments, runtime engine 300 may be distributed among threads in other ways.

The following subsections describe example embodiments for collecting profile information.

B. Example embodiments for collecting Profile information

As described above in connection with FIGS. 3 and 4, profile generator 204 is configured to analyze bytecode 324 to collect statistics and further historical information about source code 208 to generate profile information 320. The profile generator 204 may be configured in various ways to perform its functions. For example, FIG. 5 shows a block diagram of the profile generator 204, according to an example embodiment. As shown in FIG. 5, profile generator 204 includes a code profiler (profiler) 502, a startup profiler 504, and a script library profiler 506. In embodiments, the profile generator 204 may include any one or more of these features. The profile generator 204 of FIG. 5 is described below.

Code profiler 502 is configured to analyze bytecode 324 for patterns that occur multiple times and generate statistics and/or other historical information about patterns that are included in profile information 320. This historical pattern information may be used to detect the presence of frequently executed functions ("hot spots"), loop bodies, helper calls, attribute accesses, etc. in bytecode 324. By indicating the existence of such patterns, such as by enabling the generation of machine code for commonly occurring patterns, this historical pattern information may be used to more efficiently execute the source code 208.

For example, code profiler 502 may monitor and track how many times a particular script function is executed in bytecode 324 during execution of source code 208. In the profile information 320, the code profiler 502 may display an identifier or name of a function (e.g., in bytecode form or otherwise) in association with the number of times the function was executed during execution of the bytecode 324.

In an embodiment, each function of the script may have a corresponding function identifier (e.g., numeric identifier, alphanumeric identifier, etc.) assigned thereto in the profile information 320. The function identifier may be generated in any manner (e.g., by sequentially numbering the functions as they are profiled, generating a hash value for each function, etc.) and may be used to uniquely identify each function in the profile information 320 for any purpose. For example, an index may be stored that maps functions in bytecode 324 to their respective identifiers. During subsequent execution of source code 208, each time a function in bytecode 324 is encountered, the index is accessed to determine the identifier assigned to the function. The identifier may then be located in the profile information 320 to locate any stored profile information for the function.

In another example, code profiler 502 may monitor and track how many times a loop ("code loop" or "loop body") of a particular code within bytecode 324 is executed during execution of source code 208. In profile information 320, code profiler 502 may, for example, indicate a start instruction and an end instruction for a code loop to identify the code loop, or may indicate the code loop in another manner. Code profiler 502 may indicate, in association with the identified code loop, the number of times the code loop is executed.

In another example, code profiler 502 may monitor and track objects (e.g., variables) in bytecode 324. For example, in profile information 320, code profiler 502 may indicate an object and may indicate one or more of the following each time the object is accessed and/or modified: the type of the object (e.g., integer, floating point value, etc.), the shape of the object (e.g., properties of the object), and/or other object characteristics. In other examples, code profiler 502 may monitor and track characteristics of an array (e.g., array type or array boundaries), values of object properties, and the like.

The code profiler 502 may also indicate in the profile information 320 any portions of the bytecode 324 that are unused (not executed), including any functions, objects, loops, etc. that are unused. For example, source code 208 may include errors in the encoding that result in unused portions of the code, may include unused utility or library modules (e.g., only portions of libraries that are completely included in source code 208 may be used), and/or may include test code that was used during source code testing but was not used during normal operation. In embodiments, during source code execution, execution controller 308 may instruct parser 304 not to parse (or partially parse) portions of bytecode 324 that are indicated as not being used in profile information 320 to increase execution efficiency.

In other embodiments, code profiler 502 may track the generation of further statistics and/or other historical information about bytecode 324 and may include the historical information in profile information 320.

The start parser 504 is configured to parse the bytecode 324 for the bytecode used at the beginning of execution of the source code 208 and to indicate this "start" bytecode in the profile information 320. For example, in one embodiment, startup parser 504 may perform flow diagram 600 in FIG. 6. Flowchart 600 shows a process for indicating a start-up portion of source code in profile information according to an example embodiment. Flowchart 600 is described as follows.

Flowchart 600 begins with step 602. At step 602, the portion of the bytecode that is executed during startup is determined. For example, in an embodiment, boot parser 504 may determine the boot portion of bytecode 324 that was executed first when execution of source code 208 began. The start-up parser 504 may determine the start-up portion of the bytecode 324 in any manner, such as by determining a function of a predetermined number of bytecodes 324 that occur when the bytecode 324 is first received at the profile generator 204, by determining a predetermined number of instructions (e.g., a predetermined number of lines of the bytecode 324) that occur when the bytecode 324 is first received at the profile generator 204, or another manner.

At step 604, an indication of the portion of the bytecode determined to be executed during startup is stored in the profile information. For example, in one embodiment, the startup profiler 504 may indicate in the profile information 320 the startup portion determined in step 602. The start-up parser 502 may indicate the start-up portion in the profile information 320 in any manner, such as by indicating a function name or identifier, by indicating a block of bytecode by a line number, by indicating start and end instructions for the start-up portion, or in any other manner.

Script library parser 506 is configured to parse bytecode 324 for any accesses to script library modules used during execution of source code 208 and to indicate these accessed script library modules in profile information 320. For example, as shown in fig. 3, interpreter 310 and/or JIT compiler 312 may access script library 318 during execution of source code 208. The script library 318 may include one or more library modules that contain pre-encoded functions. These pre-encoded functions are accessible by source code 208, so that developers of source code 208 do not have to generate code for these functions, saving development time. For example, the script library 318 may be a JavaScript library including a pre-encoded JavaScript module, may be an AJAX library including a pre-encoded AJAX module, and/or may be a library of another dynamic language. The library modules of the scripting library 318 may be parsed by the parser 304 and converted by bytecode, if necessary, by the bytecode generator 306 before being interpreted and/or compiled. In embodiments, during source code execution, execution controller 308 may instruct parser 304 not to parse library modules of script library 318 that are not indicated to be used in profile information 320 to increase execution efficiency.

In an embodiment, script library parser 506 may execute flow diagram 700 in FIG. 7. Flowchart 700 provides a process for generating profile information for a script library according to an example embodiment. Flowchart 700 is described as follows.

Flowchart 700 begins with step 702. At step 702, profile information is generated for the scripting library module accessed by the source code. For example, in an embodiment, script library parser 506 may determine script library modules of script library 318 that are accessed by bytecode 324 during execution of source code 208 and may indicate these accessed script library modules in profile information 320. Script library parser 506 may indicate the script library module being accessed in any manner, including by module name, module storage location, and the like.

At step 704, the profile information generated for the scripting library module is stored. For example, as shown in FIG. 3, profile information 320, which may include accessed library module profile information, may be stored in storage 314.

Thus, various types of profile information may be collected in various ways. The collected profile information may be used to optimize (e.g., improve) the performance of the source code. The following subsections describe example embodiments for optimizing source code portions based on profile information.

C. Example embodiments that optimize portions of a script based on profile information

As described above with respect to fig. 3 and 4, execution of script source code 208 by runtime engine 300 may be improved based on profile information 320. For example, portions of bytecode 324 may be compiled and executed at runtime without being interpreted to improve script execution efficiency. In various embodiments, to improve script performance, runtime engine 300 may compile portions of the script for execution based on analysis of the script profile information.

For example, FIG. 8 shows a flowchart 800 of a process for providing portions for compiling a script based on profile information for the script, according to an example embodiment. In an embodiment, runtime engine 300 of FIG. 3 may perform flowchart 800. Other structural and operational embodiments will be apparent to those skilled in the relevant arts based on the following discussion of flowchart 800.

Flowchart 800 begins with step 802. At step 802, the profile information may be analyzed to determine a condition associated with the received portion of the bytecode. For example, as shown in fig. 3, the execution controller 308 receives the bytecode 324 and the profile information 320. In an embodiment, the execution controller 308 may analyze the profile information 320 to determine whether a portion of the bytecode 324 is to be interpreted or compiled rather than interpreted to improve execution efficiency. Various conditions during the analysis may be determined by the execution controller 308 that indicate that the received bytecode portion is to be compiled to improve execution efficiency, such as a function, loop body, typed object, bytecode associated with an array, bytecode associated with an expression, or other bytecode portion. For example, if a function is called a predetermined number of times in bytecode 324, it is desirable that the function be compiled and not interpreted.

At step 804, as a result of the determined circumstances, the bytecode portion can be compiled on-the-fly into a compiled bytecode portion. For example, as shown in fig. 3, the execution controller 308 may generate a compiler control signal 328 to instruct the JIT compiler 312 to compile the bytecode portion. Thus, when JIT compiler 312 is instructed by compiler control signals 328, JIT compiler 312 compiles portions of bytecode 324 to generate compiled bytecode 330. Compiled bytecode 330 can be referred to as "instanced" bytecode or "instanced" code because it is just-in-time compiled on request.

At step 806, the compiled bytecode portion is executed instead of interpreting the bytecode portion. For example, as shown in fig. 3, the compiled bytecode 330 is received by a machine code executor 316 (e.g., one or more processors) that executes the compiled bytecode 330. Note that step 806 may or may not be performed, depending on the particular embodiment. For example, in an embodiment, compiled bytecode 330 can be generated and executed instead of using interpreter 310 to interpret bytecode portions. In another embodiment, the bytecode portion may be interpreted using the interpreter 310, while the compiled bytecode 330 may be generated but not executed. Instead, in such embodiments, compiled bytecode 330 is generated so that it can be executed the next time the corresponding bytecode portion is encountered in bytecode 324.

At step 808, the compiled bytecode portion is stored. For example, as shown in fig. 3, compiled bytecode 330 can be stored in storage 314 for access during subsequent execution of source code 208 by runtime engine 300.

The execution controller 308 may be configured in a variety of ways to execute step 802 to detect various conditions in the profile information to select between interpreting the bytecode and compiling the bytecode. If one or more ideal conditions are detected, it may be desirable to generate compiled machine code to be executed rather than interpreted code. For example, FIG. 9 shows a block diagram of the execution controller 308 of FIG. 3, according to an example embodiment. As shown in fig. 9, the execution controller 308 includes a plurality of code execution optimizer modules, including an inlining module 902, a type specialization module 904, a field lifting module 906, a redundancy type checking module 908, a CSE (general subexpression elimination) module 910, an array boundary checking module 912, a typed array module 914, a constructor mode module 916, a field replication propagation (prop) module 918, and an initiation module 920. Any one or more of these code execution optimizer modules may be present in the execution controller 308 to detect the presence of one or more respective conditions, and to perform optimizations if the one or more conditions are detected (e.g., compiling a particular bytecode to generate machine code, etc.). These features of the execution controller 308 are described below.

The inline module 902 is configured to analyze the profile information 320 to determine the following: in this case, the bytecode portion of bytecode 324 may be executed multiple times without making changes to functions, objects, etc. within the bytecode portion. When inline module 902 determines such a bytecode portion, inline module 902 may replace the bytecode portion with machine code generated by JIT compiler 312 for that bytecode portion, in effect "inline" the machine code in bytecode 324. Machine code can be executed more quickly, improving overall program runtime efficiency. For example, the profile information 320 may indicate that the bytecode portion includes a first function that calls a second function. If the profile information 320 indicates that the first function is called multiple times and each time the second function is called, machine code for the second function may be generated for replacing the second function in the first function.

For example, in the following JavaScript example, a first function "foo ()" may call a second function "bar ()" in source code 208:

when the code is executed, the text is printed out:

Infoo()

Inbar()

however, the assignment "blah = bar" may be hidden in various ways. In this case, the JIT compiler 312 may not be able to statically determine what code will be executed when blah () is called, and the blah () may call a different function for a different call for the function foo (). The profile information 320 may indicate to the inline module 920 that the value "blah ()" always calls "bar ()" in this case. Thus, the JIT compiler 312 may generate machine code equivalent to the following script code:

in this example, the machine code of the function "bar ()" is inlined into the function "foo ()" by the inlining module 902. This increases program efficiency by avoiding the overhead of making a separate call to "bar ()". Further, in this example, "foo ()" may be configured by inline module 902 such that "bailout" occurs if "blah ()" does not call "bar ()". In this case, the original JavaScript script displayed above, rather than the version of the inlined machine code with "bar ()" of "foo ()", may be executed (via interpreter 310). The bailout is described in more detail below.

The Type Specialization (TS) module 904 is configured to analyze the profile information 320 to determine the following: in this case, the bytecode portion of bytecode 324 includes typed objects that maintain the same type during multiple (e.g., predetermined number of times, such as 2, 5, or other predetermined number of times) executions by interpreter 310. When the TS module 904 determines such a bytecode portion, the TS module 904 may direct (via signal 328) the JIT compiler 312 to compile the bytecode portion into machine code with objects having the same type as the type that has been reused. During source code execution, the execution controller 308 may point to machine code that has been generated, which can be executed more quickly than the interpreter 310 can interpret bytecode portions.

For example, with respect to JavaScript, an expression may have typed objects x, y, and w, as shown below:

{

x=y+w;

}

the TS module 904 can determine from the profile information 320 that y and w are of a type that is invariant (e.g., of integer, floating point, string type, etc.) over a number of previous executions by the interpreter 310. If their type is invariant (e.g., floating point), the TS module 904 may direct the JIT compiler 312 to compile their bytecode into machine code that assumes that y and w have types that have previously appeared. Machine code may be generated to perform the addition of "y + w", where y and w are assumed to have their particular rendering type (e.g., floating point). This improves program efficiency by avoiding the overhead of processing possibilities, which may vary from one execution iteration to the next, as is possible in dynamic languages.

Field lifting module 906 is configured to analyze profile information 320 to determine if there are any implicit calls in bytecode 324 that may not allow JIT compiler 312 to perform field lifting. To perform field lifting, JIT compiler 312 may determine that the portion of bytecode 324 that includes objects with attributes that maintain the same value during multiple executions (e.g., a predetermined number of times, such as 2, 5, or other predetermined number of times) by interpreter 310 (such as during a loop). In this case, JIT compiler 312 may compile the bytecode portion into machine code to reference previously used object attribute values in registers or other locations in which the previously used object attribute values are loaded. The field promotion module 906 may analyze the profile information 320 to determine if there are any implicit calls in the loop because these implicit calls may undesirably modify the attribute values. If no implicit call exists, machine code may be generated and used. If there is an implicit call, the machine code may not be generated. During source code execution, the execution controller 308 may point to the generated machine code, which can be executed more quickly than the interpreter 310 can interpret the bytecode portion.

For example, with respect to JavaScript, an expression may have an object "o" (denoted as "o.x") with a property "x," as shown in the following "For" loop:

For(i=0;i<1000;i++){

y=y+o.x

}

the attribute "o.x" is not constant in the following cases: (1) o is directly modified (o = o2;, (2) o.x is directly modified (o.x =10;, (3) an explicit function call modification o or o.x, or (4) an implicit function call modification o or o.x. The JIT compiler 312 may identify (1), (2), or (3). However, (4) is difficult to determine statically. For example, "y" or "o.x" may point to an object having a "value of ()" member function that is overridden by a version of the modification "o.x" itself. Thus, field promotion module 906 may determine from profile information 320 that there has not been a prior implicit invocation. In this case, the value may be loaded into a register in memory where it may be accessed quickly. JIT compiler 312 may compile the bytecode into machine code that accesses attribute values stored in registers. For example, the attribute value may be loaded into a register called "T1," which may be referenced in the generated machine code (e.g., "y = y + T1" in the above example). This improves program efficiency by avoiding the following overhead: it is assumed that the attribute values may change from one execution iteration to the next, as is possible in dynamic languages. Some runtime checks may be performed to ensure that no implicit calls occur. If an implicit call occurs during runtime, a jump to interpreter 310 may be performed.

A Redundancy Type Check (RTC) module 908 is configured to analyze the profile information 320 to determine if there are any implicit calls in the bytecode 324 that may not allow the JIT compiler 312 to perform redundancy type checks. To perform redundant type checking, JIT compiler 312 may determine portions of bytecode 324 where objects have multiple attributes, and similar type checking may be performed each time an object's attribute values are loaded in bytecode 324. In such a case, the JIT compiler 312 may compile the bytecode portion into machine code to load the attribute values more efficiently at the same time, and perform type checking on multiple attribute values of the same object together. The RTC module 908 may analyze the profile information 320 to determine whether there are any implicit calls that may change the shape of the object between two or more attribute value loads. If no implicit call exists, machine code may be generated and used. If there is an implicit call, the machine code may not be generated. During source code execution, the execution controller 308 may point to the generated machine code, which can be executed more quickly than the interpreter 310 can interpret the bytecode portion.

For example, with respect to JavaScript, object "o" may have attributes "x" and "y" (denoted as "o.x" and "o.y") in the source code that are accessed at different times, as shown below:

z=o.x;

…

w=o.y

the RTC module 908 may check the profile information 320 to determine whether there may be any implicit invocations between the two attribute value loads. If such an attribute value load exists without the potential intervention of an implicit call, the JIT compiler 312 may compile the bytecode into machine code that may cause the attribute value load and type check to be performed together in a more uniform manner. For example, attribute values may be loaded for both o.x and o.y at the same time, and type checking for o.x and o.y may be performed together. This improves program efficiency by avoiding the overhead of separate iterations of attribute value loading and type checking.

The CSE module 910 is configured to analyze the profile information 320 to determine if there are any implicit calls in the bytecode 324 that may not allow the JIT compiler 312 to perform generic sub-expression elimination. To perform generalized sub-expression elimination, JIT compiler 312 may determine the portion of bytecode 324 that includes generalized expressions that are evaluated multiple times (e.g., a predetermined number of times, such as 2 times, 5 times, or other predetermined number of times) by interpreter 310. In this case, the solution to the expression may be stored in a register or other location in memory, and the JIT compiler 312 may compile the bytecode portion into machine code to reference the expression solution in the register or other location. The CSE module 910 parses the profile information 320 to determine if there are any implicit calls between expression evaluations that can change the expression value. If no implicit call exists, machine code may be generated and used. If there is an implicit call, the machine code may not be generated. When an expression is encountered during execution, the execution controller 308 may point to the generated machine code from which the expression solution may be loaded.

For example, with respect to JavaScript, the expressions "y" and "w" may be the same, but evaluated separately, as shown in the following example:

y=a+b+c;

…

w=a+b+c;

the CSE module 910 may examine the profile information 320 to determine whether there may be any implicit calls between two expressions that change the expression value (e.g., such as by pointing to an object with a value of () function that returns a different value each time). In this case, and if it is determined that an implicit call is not possible (e.g., determined to not occur, determined to not have a high likelihood of occurring (e.g., 90% likelihood does not occur), etc.), the JIT compiler 312 may cause the expression to be evaluated and the solution stored in a register (e.g., referred to as "T1"). In addition, instead of evaluating an expression, the JIT compiler 312 may compile bytecode into machine code that loads attribute values from registers, as follows:

T1=a+b+c;

y=T1;

…

w=T1;

this improves program efficiency by avoiding the overhead of evaluating an expression multiple times.

An Array Boundary Check (ABC) module 912 is configured to analyze the profile information 320 to check for instances of the bytecode portion of the bytecode 324 that includes an array. ABC module 912 may direct JIT compiler 312 (via signal 328) to compile the bytecode portion into machine code that processes the array more efficiently. For example, the ABC module 912 may check whether the object is an array, whether the index applied to the array is within a pre-set boundary of the array, and if so, enable the JIT compiler 312 to generate machine code that enables the values for the array to be loaded directly from the array.

For example, with respect to JavaScript, the array "A [ i ]" may be defined to have a length of "length" in a "For" loop, as shown below:

For(i=0;i<A.length:i++)

{

x=x+A[i]

}

in this example, ABC module 912 may check whether "A [ i ]" is an array and whether the value of "i" is within the bounds of array "A [ i ]" (e.g., is less than "length"). If profile information 320 indicates that the value of "i" has been within a pre-set boundary during a previous iteration, ABC module 912 may direct JIT compiler 312 to compile the portion of bytecode corresponding to the above code into machine code so that array values may be loaded directly from array "A [ i ]" stored in memory. This increases program efficiency by avoiding the overhead of checking the array "A [ i ]" multiple times. However, if the ABC module 912 determines that "i" has been previously outside the boundaries of the array "A [ i ]", then the optimization may not be made.

The Typed Array Module (TAM) module 914 is configured to analyze the profile information 320 to check for the following: in this case, the bytecode portion of bytecode 324 includes a typed array that is evaluated by interpreter 310 according to a particular type. If the profile information 320 indicates that an array is evaluated consecutively as having the same type (e.g., integer array, floating point array, string array, etc.), the ABC module 912 may direct (via signal 328) the JIT compiler 312 to compile the bytecode portion into machine code that processes the array according to the particular type.

For example, with respect to JavaScript, the array "A [ i ]" may be used in an expression, as shown in the following example:

x+=A[i]

JavaScript supports various types of arrays, including normal arrays containing any type of value, floating point arrays (including only floating point numbers), integer arrays (including only integers), and the like. Without the profile information 320, the array "A [ i ]" may be considered a normal array. If profile information 320 indicates that the array "A [ i ]" has previously included a single type, ABC module 912 may direct (via signal 328) JIT compiler 312 to compile the bytecode portion for the above expression into machine code that processes the array according to the particular type. This increases program efficiency by avoiding the overhead of processing all possible types of arrays "A [ i ]".

Builder mode module 916 is configured to analyze profile information 320 to determine if there are any implicit calls in bytecode 324 that may not allow JIT compiler 312 to perform builder mode optimization. To perform builder mode optimization, JIT compiler 312 may determine a portion of bytecode 324 that indicates an object was built during execution of interpreter 310. In this case, JIT compiler 312 may compile the bytecode portion into machine code to more efficiently construct the object. Builder mode module 916 analyzes profile information 320 to determine if there are any implicit calls (as these implicit calls may add/delete fields) when an object is built. If no implicit call exists, machine code may be generated and used. If there is an implicit call, the machine code may not be generated. During source code execution, the execution controller 308 may point to the generated machine code, which can be executed more quickly than the interpreter 310 can interpret the bytecode portion.

For example, with respect to JavaScript, the object "o" may be constructed by adding attributes thereto, such as the three attributes "x", "y", and "w" in three separate statements as shown in the following example:

o.x=1

o.y=2

o.w=3

in this example, object "o" does not include the attributes "x", "y", and "w" prior to the above three statements. As shown above for this example, when an attribute is added to the object "o," a value is assigned to each attribute. Constructor mode module 916 can check profile information 320 to determine if any implicit calls occur that can change the shape of object "o" when object "o" is constructed. If it is determined that an implicit call is not possible, JIT compiler 312 may compile the bytecode into the following machine code: the machine code adds three properties to the object "o" in a single operation and captures the property values for the three properties. This improves program efficiency by avoiding the overhead of adding multiple attributes to an object through multiple separate operations.

A field copy propagation module (FCP) 918 is configured to analyze the profile information 320 to determine if there are any implicit calls in the bytecode 324 that may not allow the JIT compiler 312 to perform field copy propagation. To perform field replication propagation, JIT compiler 312 can determine the bytecode portion of bytecode 324 that includes references to previously-assigned object properties. In this case, JIT compiler 312 may compile the bytecode portion into machine code that replaces the object property references with previously assigned values. The FCP module 918 analyzes the profile information 320 to determine if there are any implicit calls between references that can change the attribute values. If no implicit call exists, machine code may be generated and used. If there is an implicit call, the machine code may not be generated. During source code execution, the execution controller 308 may point to the generated machine code, which can be executed more quickly than the interpreter 310 can interpret the bytecode portion.

For example, as shown below with respect to JavaScript, object "o" can have an attribute "x" assigned a value of "1", and then object "y" can have a value of attribute value "x":

o.x=1

…

y=o.x

the FCP module 918 can check the profile information 320 to determine if any implicit calls occur between the two operations on o.x (which can change the value of o.x). In this case, and if it is determined that an implicit call is not possible, the "o.x" expression may be replaced with the actual value "1" (e.g., y = 1). JIT compiler 312 may compile the bytecode into machine code that replaces "o.x" with a value of "1". This increases program efficiency by avoiding the overhead of looking up an attribute value each time "o.x" is encountered in the bytecode.

The startup module 920 is configured such that when the script is executed, the startup bytecode is executed first. For example, as described above, the startup parser 504 of FIG. 5 is configured to parse the bytecode 324 to find the bytecode used at the beginning of execution of the source code 208 and indicate the "startup" bytecode in the profile information 320. The start module 920 of fig. 9 is configured such that when the script begins execution, the start bytecode indicated in the profile information 320 is executed before the other bytecodes.

For example, FIG. 10 shows a flowchart 1000 providing a process for using profile information to improve script launching, according to an example embodiment. In an embodiment, the initiation module 920 may perform the flowchart 1000. Flowchart 1000 is described as follows.

Flowchart 1000 begins with step 1002. At step 1002, profile information is accessed to determine the bytecode portion to be executed during startup. As described above, the start module 920 may access the profile information 320 to determine the indicated start bytecode to be executed at the beginning of execution of the source code 208. In an embodiment, the start bytecode may be associated with an identifier of the source code 208. For example, in an embodiment, the boot parser 504 of FIG. 5 may generate a hash value or other identifier for the source code 208 when the boot bytecode of the source code 208 is identified. The hash value (or other identifier) may be indicated in the profile information 320 along with an indication to start the bytecode. When source code 208 is executed from scratch again, start module 920 may generate a hash value (or other identifier) for source code 208 and may compare the generated hash value to the hash value stored in profile information 320 to identify source code 208 and its indicated start bytecode. In other embodiments, the start bytecode of source code 208 may be identified in profile information 320 in other manners.

At step 1004, the determined portion of the boot bytecode is parsed and converted to bytecode before parsing the remainder of the source code and converting to bytecode. For example, once the initiation module 920 determines the initiation bytecode in the profile information 320, the initiation module 920 may instruct the parser 304 of fig. 3 to parse the portion of the source code corresponding to the initiation bytecode before parsing any other portion of the source code. In this manner, the bytecode generator 306 first generates the start bytecode, and the source code 208 can begin execution more quickly.

As such, compiled bytecode for portions of the source code may be generated based on the profile information. Compiled bytecode can be executed so that the source code can be executed more efficiently. Further, the compiled bytecode can be saved to be used during future source code execution. The following subsections describe example embodiments for subsequent source code execution enhanced using stored compiled bytecode.

D. Example embodiments for improving subsequent script execution based on profile information

As described above, based on profile information, portions of the script may be compiled and executed on the fly rather than interpreted to improve script execution efficiency. In embodiments, the profile information may be saved in persistent storage for later use during current execution of the script, and/or for use in future execution of the script. For example, profile information may be accessed in persistent storage and cached in memory for use during subsequent script execution. Additional profile information may or may not be generated during such subsequent script execution. By accessing previously generated profile information, scripts may be executed more efficiently using previously generated machine code.

The runtime engine 300 of FIG. 3 may be used to improve script execution performance in various embodiments by using previously generated profile information in various ways. For example, FIG. 11 shows a block diagram of the execution controller 308 of FIG. 3, according to an example embodiment. As shown in fig. 11, the execution controller 308 includes a Compiled Code (CC) detector 1102, a condition checker 1104, and a Condition Check Failure (CCF) tracker 1106. In various embodiments, any one or more of these features may be included in the execution controller 308. These features of the execution controller 308 are described below.

CC detector 1102 is configured to check whether compiled bytecode for currently executed bytecode 324 has been generated and stored in storage. For example, fig. 3 shows compiled bytecode 332 stored in storage 314. Compiled bytecode 332 includes compiled bytecode that was previously generated by JIT compiler 312 for execution. If CC detector 1102 determines that there is compiled bytecode in storage for the portion of bytecode 324 to be executed, CC detector 1102 may cause the compiled bytecode to be executed (e.g., by machine code executer 316) instead of the bytecode being interpreted by interpreter 310 or compiled by JIT compiler 332.

The condition checker 1104 is configured to perform one or more checks on the compiled bytecode (e.g., the compiled bytecode 332) to verify that a condition desired by the compiled bytecode is satisfied. If one or more of the desired conditions fail, then condition checker 1104 can direct execution of bytecode 324 to interpreter 310, which interpreter 310 executes bytecode 324 at the appropriate point instead of compiled bytecode 332.

CCF tracker 1106 is configured to track failure of a condition as determined by condition checker 1104. CCF tracker 1106 may maintain statistics on conditions of failure and if a sufficient number of conditions of failure are registered for a compiled bytecode portion, CCF tracker 1106 may instruct JIT compiler 312 to compile a new version of the encoded bytecode portion (to replace the compiled bytecode portion with a failure).

FIG. 12 shows a flowchart 1200 providing a process for executing a script, according to an example embodiment. In an embodiment, runtime engine 300 of FIG. 3 may perform flowchart 1200. Other structural and operational embodiments will be apparent to those skilled in the relevant arts based on the following discussion of flowchart 1200. The flow diagram 1200 is described below in conjunction with FIG. 13, which FIG. 13 shows the runtime engine 300 of FIG. 3.

Flowchart 1200 begins at step 1202. At step 1202, a bytecode portion of a bytecode is received. For example, as shown in fig. 13, a bytecode portion (e.g., function, loop, etc.) in bytecode 324 is received by execution controller 308.

At step 1204, it is determined whether the compiled bytecode for the received bytecode portion has been stored. For example, referring to fig. 11, CC detector 1102 may determine whether compiled bytecode for the received portion of bytecode 324 is present in storage 314 of fig. 13. If the compiled bytecode does not exist, operation proceeds from step 1204 to step 1206. If compiled bytecode exists, operation proceeds from step 1204 to step 1208.

At step 1206, the received bytecode portion is interpreted. The interpreter 310 of fig. 3 may be enabled by the execution controller 308 to interpret the bytecode portion of the bytecode 324 because a compiled version of the bytecode portion does not already exist. For example, in an embodiment, execution controller 308 may direct the execution of bytecode 324 to an address of interpreter 310, or may enable interpreter 310 to interpret the bytecode portion in other ways.

Note that alternatively, rather than performing step 1206 to interpret the bytecode portion, operations may proceed from step 1204 to step 802 of flowchart 800 (FIG. 8) to determine whether the bytecode portion can be optimized.

At step 1208, at least one condition check is performed on the compiled bytecode portion. In an embodiment, the condition checker 1104 of FIG. 11 can perform one or more condition checks on compiled portions of bytecode already present in the storage 314. For example, one or more condition checks may be performed depending on the particular code execution optimizer module (FIG. 9) that was used to generate the compiled bytecode portion.

For example, machine code for the second function may be generated by inlining module 902 into the first function in bytecode 324 according to a previous history indicated in profile information 310. However, if the condition checker 1104 determines in a subsequent execution that a function other than the second function was executed in the bytecode 324 during the first function, then a failure condition occurs.

Other code optimizer modules of FIG. 9 may rely on no changes to related objects, attributes, types, expressions, calls to functions, and/or other bytecode characteristics in bytecode 324. However, if such a change occurs, a failure situation may occur. For example, the TS module 904 can assume that no type changes have occurred to the related objects; the field promotion module 906 may assume that no hidden/implicit calls have occurred that change the associated attribute values; the RTC module 908 may assume that no changes to the structure of the associated object have occurred; the CSE module 910 may assume that no hidden/implicit calls have occurred that change the relevant object value; the ABC module 912 may assume that the array index value does not exceed the boundary; the typed array module 914 may assume that no changes to the type of the related array have occurred; constructor schema module 916 can assume that no changes to the values of any expression objects have occurred; and the FCP module 918 may assume that the associated object property values have not changed. For each of these optimizations, a failure of the situation occurs if the critical assumption becomes incorrect.

At step 1210, it is determined whether one or more of the condition checks pass. If the condition check of step 1208 fails, then operation proceeds from step 1210 to step 1206. If the one or more condition checks of step 1210 pass, then operation proceeds from step 1210 to step 1212.

At step 1212, the compiled bytecode portion is executed instead of interpreting the received bytecode portion. For example, since there is a compiled bytecode for a portion of bytecode 324 and any condition check for the compiled bytecode portion passes, then the compiled bytecode portion can be executed. In an embodiment, the execution controller 308 may direct execution of the compiled bytecode portion in the storage 314 to an address of the machine code executor 316, or may launch the machine code executor 316 to execute the compiled bytecode portion in any other manner. For example, as shown in fig. 13, compiled bytecode 332 received at machine code executer 316 is to be executed.

Note that if the operation proceeds from step 1210 to step 1206 due to a case failure, a "bailout" may be considered to occur. In "jump out," instead of executing the bytecode that has already been compiled, the corresponding bytecode portion in bytecode 324 is interpreted by interpreter 310. Such a jump-out is a relatively expensive process because the slower bytecode interpretation is executed instead of executing the machine code. Thus, in an embodiment, a code module configured to correct a failed condition (e.g., "helper code") may be executed instead of performing a jump out that is dependent on the condition failure, and execution of the compiled portion of bytecode may continue. Such helper code may be generated for any one or more of the code execution optimizer modules described above. For example, with respect to the TS module 904 and typed array module 914, helper code may be executed to handle the undesirable type changes that occur.

The Condition Check Failure (CCF) tracker of FIG. 11 may perform its functions in a variety of ways. For example, FIG. 14 shows a flowchart 1400 providing a process for tracking situational checks of compiled bytecode, according to an example embodiment. Other structural and operational embodiments will be apparent to those skilled in the relevant arts based on the following discussion of flowchart 1400.

Flowchart 1400 begins with step 1402. At step 1402, check failures are tracked for any one or more conditions of the compiled bytecode portion. For example, as described above with respect to fig. 11, CCF tracker 1106 can record any condition failures detected by condition checker 1104. For example, CCF tracker 1106 can maintain a table or other data structure in storage (e.g., in memory) that indicates one or more compiled bytecode portions that have case failures (e.g., via respective identifiers, etc.) and indicates, for each indicated compiled bytecode portion, a number of case failures that have occurred.

At step 1404, it is determined whether a predetermined number of condition checking failures have occurred. In an embodiment, CCF tracker 1106 may compare the number of case failures indicated for the compiled bytecode portion to a predetermined unacceptable number of case failures (e.g., 1, 2, 5, or other value).

At step 1406, the bytecode portion is compiled into a second compiled bytecode portion. For example, in an embodiment, for each compiled bytecode portion that fails up to a predetermined number of instances, CCF tracker 1106 may instruct JIT compiler 312 to recompile the bytecode corresponding to the failed compiled bytecode portion to generate a new compiled bytecode portion. Previous versions of the compiled bytecode portion may be deleted, and a new compiled bytecode portion may be stored in storage 314 for future access.

Example computing device embodiments

Runtime engine 202, profile generator 204, parser 304, bytecode generator 306, execution controller 308, interpreter 310, JIT compiler 312, machine code executor 316, code profiler 502, startup profiler 504, scripting library profiler 506, inlining module 902, type specialization module 904, field promotion module 906, redundancy type check module 908, CSE module 910, array boundary check module 912, typed array module 914, constructor mode module 916, field replication propagation module 918, startup module 920, code to compile detector 1102, condition checker 1104, condition check failure tracker 1106, flowchart 400, flowchart 600, flowchart 700, flowchart 800, flowchart 1000, flowchart 1200, and flowchart 1400 may be implemented in hardware, software, firmware, or any combination thereof.

Such as runtime engine 202, profile generator 204, parser 304, bytecode generator 306, execution controller 308, interpreter 310, JIT compiler 312, machine code executor 316, code profiler 502, startup profiler 504, script library profiler 506, inlining module 902, type specialization module 904, field promotion module 906, redundant type checking module 908, CSE module 910, array bounds check module 912, typed array module 914, constructor mode module 916, field copy propagation module 918, startup module 920, code to compile detector 1102, condition checker 1104, condition check failure tracker 1106, flowchart 400, flowchart 600, flowchart 700, flowchart 800, flowchart 1000, flowchart 1200, and/or flowchart 1400 may be implemented as computer program code configured to be executed in one or more processors. Alternatively, runtime engine 202, profile generator 204, parser 304, bytecode generator 306, execution controller 308, interpreter 310, JIT compiler 312, machine code executor 316, code profiler 502, startup profiler 504, script library profiler 506, inlining module 902, type specialization module 904, field promotion module 906, redundant type check module 908, CSE module 910, array boundary check module 912, typed array module 914, constructor mode module 916, field replication propagation module 918, startup module 920, code to compile detector 1102, condition checker 1104, condition check failure tracker 1106, flowchart 400, flowchart 600, flowchart 700, flowchart 800, flowchart 1000, flowchart 1200, and/or flowchart 1400 may be implemented as hardware logic/circuitry. For example, in one embodiment, one or more of runtime engine 202, profile generator 204, parser 304, bytecode generator 306, execution controller 308, interpreter 310, JIT compiler 312, machine code executor 316, code profiler 502, startup profiler 504, script library profiler 506, inlining module 902, type specialization module 904, field promotion module 906, redundancy type check module 908, CSE module 910, array boundary check module 912, typed array module 914, constructor mode module 916, field replication propagation module 918, startup module 920, code to compile detector 1102, condition checker 1104, condition check failure tracker 1106, flowchart 400, flowchart 600, flowchart 700, flowchart 800, flowchart 1000, flowchart 1200, and/or flowchart 1400 may be implemented in a system on a chip (SOC). The SoC may include an integrated circuit chip including one or more of: a processor (e.g., a microcontroller, microprocessor, Digital Signal Processor (DSP), etc.), a memory, one or more communication interfaces, and/or further circuitry for performing its functions and/or embedded firmware.

FIG. 15 depicts an exemplary implementation of a computer 1500 in which embodiments of the present invention may be implemented. For example, computing device 102 and/or server 104 may be implemented in a computer system similar to computer 1500 that includes one or more features of computer 1500 and/or alternative features. Computer 1500 may be a general-purpose computing device in the form of a conventional personal computer, a mobile computer, a server, or a workstation, for example, or computer 1500 may be a special purpose computing device. The description of computer 1500 provided herein is provided for purposes of illustration, and is not intended to be limiting. As will be appreciated by one skilled in the relevant art, embodiments of the invention may be implemented in other types of computer systems.

As shown in fig. 15, the computer 1500 includes one or more processors 1502, a system memory 1504, and a bus 1506 that couples various system components including the system memory 1506 to the processors 1502. Bus 1506 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory 1504 includes Read Only Memory (ROM)1508 and Random Access Memory (RAM) 1510. A basic input/output system 1512 (BIOS) is stored in ROM 1508.

Computer 1500 also has one or more of the following drives: a hard disk drive 1514 for reading from and writing to a hard disk, a magnetic disk drive 1518 for reading from or writing to a removable magnetic disk 1516, and an optical disk drive 1522 for reading from or writing to a removable optical disk 1520 such as a CDROM, DVDROM, or other optical media. Hard disk drive 1514, magnetic disk drive 1516, and optical disk drive 1520 are connected to bus 1506 by a hard disk drive interface 1524, a magnetic disk drive interface 1526, and an optical drive interface 1528, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of computer-readable storage media can be used to store data, such as flash memory cards, digital video disks, Random Access Memories (RAMs), Read Only Memories (ROMs), and the like.

Several program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 1530, one or more application programs 1532, other program modules 1534, and program data 1536. The application programs 1532 or program modules 1534 may include, for example, computer program logic (e.g., computer program code) for implementing the following: runtime engine 202, profile generator 204, parser 304, bytecode generator 306, execution controller 308, interpreter 310, JIT compiler 312, machine code executor 316, code profiler 502, startup profiler 504, script library profiler 506, inlining module 902, type specialization module 904, field promotion module 906, redundant type checking module 908, CSE module 910, array bounds check module 912, typed array module 914, constructor mode module 916, field copy propagation module 918, startup module 920, code to compile detector 1102, condition checker 1104, condition check failure tracker 1106, flowchart 400, flowchart 600, flowchart 700, flowchart 800, flowchart 1000, flowchart 1200, and/or flowchart 1400 (including any steps of flowcharts 400, 600, 700, 800, 1000, 1200, and 1400), and/or other embodiments described herein.

A user may enter commands and information into the computer 1500 through input devices such as a keyboard 1538 and pointing device 1540. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processor 1502 through a serial port interface 1542 that is coupled to the bus 1506, but may be connected by other interfaces, such as a parallel port, game port, or a Universal Serial Bus (USB).

A display device 1544 is also connected to bus 1506 via an interface, such as a video adapter 1546. In addition to the monitor, computer 1500 may include other peripheral output devices (not shown), such as speakers and printers.

Computer 1500 is connected to a network 1548 (e.g., the Internet) through an adapter or network interface 1550, a modem 1552, or other means for establishing communications over the network. Modem 1552, which may be internal or external, is connected to bus 1506 via serial port interface 1542.

As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium" are used to generally refer to media such as the hard disk associated with hard disk drive 1514, removable magnetic disk 1518, removable optical disk 1522, as well as other media such as flash memory cards, digital video disks, Random Access Memories (RAMs), Read Only Memories (ROM), and the like. These computer-readable storage media are distinct and non-overlapping with respect to communication media (which does not include communication media). Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media. Embodiments are also directed to these communication media.

As indicated above, computer programs and modules (including application programs 1532 and other program modules 1534) may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such computer programs may also be received via network interface 1550 or serial port interface 1542. Such computer programs, when executed or loaded by an application, enable computer 1500 to implement features of the present invention as discussed herein. Accordingly, such computer programs represent controllers of the computer 1500.

The present invention also relates to a computer program product comprising software stored on any computer usable medium. Such software, when executed in one or more data processing devices, causes the data processing devices to operate as described herein. Embodiments of the present invention employ any computer-usable or computer-readable medium, known now or in the future. Examples of a computer-readable medium include, but are not limited to, storage devices such as RAM, hard drives, floppy disks, CDROM, DVDROM, zip disks, tapes, magnetic storage devices, optical storage devices, MEM (memory), nanotechnology-based storage devices, and the like.

Conclusion VI

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those of ordinary skill in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims. Thus, the scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (11)

1. A method (400) within a computing device, comprising:

receiving source code encoded in a dynamic language for execution;

parsing (402) the source code to generate parsed source code;

converting (404) the parsed source code into bytecode;

interpreting (406) the bytecode using an interpreter;

generating (408) profile information about the bytecode;

storing (410) the profile information;

analyzing the profile information to determine a condition associated with the received portion of the bytecode;

as a result of the determined circumstances, compile the bytecode portion in-time into a compiled bytecode portion;

storing the compiled bytecode portion;

determining that a compiled bytecode portion corresponding to the received bytecode portion is stored;

performing at least one condition check on the compiled bytecode portion to verify that a condition expected for the compiled bytecode portion is satisfied; and

if the at least one condition check passes, then the compiled bytecode portion is executed instead of interpreting the received bytecode portion.

2. The method of claim 1, further comprising:

tracking any condition check failures that occur with respect to the compiled bytecode portion; and

compiling the bytecode portion into a second compiled bytecode portion if a predetermined number of condition checking failures occur.

3. The method of claim 1, wherein the generating profile information for the bytecode includes:

storing profile information indicative of at least one of: a loop body in the bytecode, a function called in the bytecode, or a number of times the function is called during execution.

4. The method of claim 1, wherein the generating profile information for the bytecode includes:

determining a portion of the bytecode that is executed during startup;

storing, in profile information, an indication of a portion of the bytecode determined to be executed during startup; and

during the subsequent execution of the source code,

accessing the profile information to determine a portion of the bytecode that is indicated to be executed during startup, an

The determined portion is parsed and the parsed determined portion is converted to bytecode before any remaining portion of the source code is parsed and converted to bytecode.

5. The method of claim 1, further comprising:

generating profile information about a scripting library module accessed by the source code; and

storing the profile information generated for the scripting library module.

6. A runtime engine (300) within a computing device, comprising:

a parser (304) that receives source code (208) encoded in a dynamic language and parses the source code to generate parsed source code (322);

a bytecode generator (306) that converts the parsed source code (322) into bytecode (324);

an execution controller (308) comprising a condition checker configured to perform at least one condition check on the compiled bytecode portion to verify that a desired condition of the compiled bytecode portion is satisfied;

an interpreter (310) that interprets the bytecode (324) when enabled by the execution controller (308);

a just-in-time JIT compiler (312) configured to compile the bytecode (324) when enabled by the execution controller (308); and

a profile generator (204) that generates profile information (320) from the bytecode (324) and stores the profile information (320);

a machine code executor;

wherein the execution controller is configured to analyze the profile information to determine a condition associated with the received portion of the bytecode; and

the execution controller is further configured to enable the JIT compiler to compile the bytecode portion into a compiled bytecode portion based on the determined condition and to enable the JIT compiler to store the compiled bytecode portion;

the execution controller is further configured to determine that a compiled bytecode portion corresponding to the received bytecode portion is stored; and

the machine code execution is further comprised to execute the compiled bytecode portion instead of interpreting the received bytecode portion if the at least one condition check passes.

7. A system within a computing device, comprising:

means for receiving source code encoded in a dynamic language for execution;

means for parsing (402) the source code to generate parsed source code;

means for converting (404) the parsed source code into bytecode;

means for interpreting (406) the bytecode using an interpreter;

means for generating (408) profile information about the bytecode;

means for storing (410) the profile information;

means for analyzing the profile information to determine a condition associated with the received portion of the bytecode;

means for, as a result of the determined circumstances, just-in-time compiling the bytecode portion into a compiled bytecode portion;

means for storing the compiled bytecode portion;

means for determining that a compiled bytecode portion corresponding to the received bytecode portion is stored;

means for performing at least one condition check on the compiled bytecode portion to verify that a condition expected for the compiled bytecode portion is satisfied; and

means for executing the compiled bytecode portion instead of interpreting the received bytecode portion if the at least one condition check passes.

8. The system of claim 7, further comprising:

means for tracking any condition check failures that occur with respect to the compiled bytecode portion; and

means for compiling the bytecode portion into a second compiled bytecode portion if a predetermined number of condition checking failures occur.

9. The system of claim 7, wherein the means for generating profile information for the bytecode comprises:

means for storing profile information indicative of at least one of: a loop body in the bytecode, a function called in the bytecode, or a number of times the function is called during execution.

10. The system of claim 7, wherein the means for generating profile information for the bytecode comprises:

means for determining a portion of the bytecode that is executed during startup;

means for storing in profile information an indication of a portion of the bytecode determined to be executed during startup; and

for use during subsequent execution of the source code,

means for accessing said profile information to determine a portion of the bytecode that is indicated to be executed during startup, an

Means for parsing the determined portion and converting the parsed determined portion into bytecode before parsing and converting any remaining portion of the source code into bytecode.

11. The system of claim 7, further comprising:

means for generating profile information about a scripting library module accessed by the source code; and

means for storing profile information generated for the scripting library module.