Persistent annotation of syntax diagrams for code optimization

Abstract

Locate and record optimization opportunities to enhance code transformation by the compiler or interpreter. The enhanced converter scans the program syntax graph, identifies subgraph structures, and annotates the nodes of the graph to record the optimization characteristics of the program code entity associated with the node. The subgraph structure and corresponding annotations can be maintained in an optimization directory that is different from any specific optimizable program. The optimizer improves program code transformation based on the annotated syntax graph. The optimization characteristics can specify the code purity with respect to execution value ranges and execution behaviors (e.g., side effects, local or global variable usage, I / O, reference parameters), and which exceptions are possible. The subgraph structure can be identified using routine names, hash values, and templates with holes that any constants will fill. Parent node characteristics can be inferred based on the characteristics of child nodes. Optimization candidates can be prioritized using weight functions. Optimizer callbacks can be inserted to incrementally evaluate optimization characteristics.

Description

Background Art

[0001] Software development activities usually include converting source code to obtain executable code. Conversion can be completed by a compiler, which converts the source code to produce executable code by relatively large segments (such as, entire files). Or, conversion can be completed by an interpreter, which produces executable code in smaller segments, for example, once converting a single programming language statement and then executing it. Because many compilers use a larger amount of source code than many interpreters during a given conversion, compilers usually have more opportunities than interpreters to optimize the executable code produced by conversion. However, optimization is not limited to the conversion activities performed by a compiler.

[0002] Optimization can reduce the amount of memory used by the executable code, or, for example, reduce the amount of time required to run the executable code. However, whether an optimization is usable in practice, rather than just in theory, depends on a number of factors. A given converter must correctly identify that a given optimization is possible given the specific source code and given the specific target processor and target execution environment. Furthermore, for the optimization to be usable in practice, the converter must be able to generate executable code that specifically implements the optimization without breaking the program. That is, an optimized version of the executable code of a program should have the same behavior as a non-optimized version of the program with respect to all program inputs and corresponding outputs; altered behavior indicates a broken program. For example, the optimized version does the same thing as the non-optimized version, but does it faster or uses less memory.

[0003] Because of such dependencies and because of other factors such as the complexity of code optimization and the often lack of visibility of optimizations from a developer's perspective, code optimization is often an ad hoc effort where many opportunities for optimization are missed. Summary of the Invention

[0004] Some embodiments utilize or perform operations that search for optimization opportunities during code transformation. These operations scan at least a portion of a program's syntax graph. The syntax graph has nodes that represent aspects of the program's grammatical structure. The operations also identify program code associated with the nodes of the syntax graph that have optimization properties and annotate the syntax graph based on the identified optimization properties. Embodiments can then generate optimizations for the program based at least in part on the annotated syntax graph.

[0005] Some embodiments of the teachings presented herein include or are associated with code conversion optimization functionality that includes digital hardware configured to perform certain operations. These operations may include (a) traversing at least a portion of a syntax graph of a program, (b) identifying a predetermined subgraph structure in the syntax graph, (c) associating an optimization property annotation with the identified syntax subgraph structure, the resulting association indicating the extent to which an aspect of the code segment corresponding to the identified subgraph structure is discernible prior to execution of the code segment, the aspect including an execution value or an execution effect or both, and (d) performing an optimization of the code conversion of the program based at least in part on a result of the associating step.

[0006] Other technical activities related to the teachings herein will also become apparent to those skilled in the art. The examples provided are illustrative only. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Rather, this Summary is provided to introduce some technical concepts in a simplified form, which are further described below in the Detailed Description. Innovation is defined by the claims, and in the event of a conflict between this Summary and the claims, the claims shall prevail. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A more detailed description will be given with reference to the accompanying drawings, which illustrate only selected aspects and, therefore, are not intended to be exhaustive in determining coverage or scope.

[0008] Figure 1 is a block diagram generally illustrating a computer system and also generally illustrating configured storage media;

[0009] Figure 2 is a block diagram illustrating a computing environment having transcoding functionality;

[0010] Figure 3 is a block diagram illustrating some examples of transcoding environments;

[0011] Figure 4 is a block diagram illustrating aspects of a system configured for optimizing code conversion of annotation functionality using syntax diagrams;

[0012] Figure 5 is a block diagram illustrating some execution-related aspects of a code segment;

[0013] Figure 6 is a block diagram illustrating optimizing directory entries;

[0014] Figure 7 is a block diagram illustrating a syntax subgraph structure identification;

[0015] Figure 8is a block diagram illustrating some functionality of some values in some optimization feature annotations;

[0016] Figure 9 is a block diagram illustrating some examples of different kinds of optimization;

[0017] Figure 10 It is a grammatical diagram;

[0018] Figure 11 is another grammatical diagram;

[0019] Figure 12 is a flow chart illustrating steps in some transcoding optimization methods; and

[0020] Figure 13 is a flow chart further illustrating some steps in the transcoding optimization method. DETAILED DESCRIPTION

[0021] Overview

[0022] Many innovations transcend their origins, but understanding the origins of an innovation can help people understand the innovation more completely. In the current context, some of the teachings described herein are driven by the technical challenges of optimizing the function code in the library. The relevant aspects of library functions are generally unknown to the compiler, so the functions are not susceptible to optimizations such as constant merging. In constant merging, certain executable code is replaced by constant values without breaking the program. However, the teachings presented herein are not limited to this context. Other technical challenges solved by the innovations taught herein will also be apparent to those skilled in the art based on the discussion provided below.

[0023] As a driving example, compilers typically include an optimization step that performs constant merging in order to reduce the execution time of the generated code by evaluating parts of the program at compile time. These optimizations are typically based on built-in knowledge of primitive data types and built-in knowledge that their operations are safe to optimize. Relevant aspects of library functions (such as the degree of their functional purity) (e.g., regarding exceptions or side effects) are typically unknown to the compiler. Therefore, library functions and their execution contexts are less suitable for some optimizations. This innovative disclosure describes a rich semantic mechanism that provides information to the compiler to allow it to perform more thorough optimizations.

[0024] Some of the embodiments described herein may be viewed by some in a broader context. For example, concepts such as annotations, constancy, execution, optimization, syntax, and transformations may be viewed as being relevant to a particular embodiment. However, it is not necessary to follow that proprietary rights seek usability in a broad context for abstract ideas herein; it is not so. Instead, the present disclosure focuses on providing appropriate specific embodiments whose technical effects solve, in whole or in part, specific technical problems, such as how to make information about program optimization opportunities available outside the context of a particular compilation or a particular development environment. Other configured storage media, systems, and processes involving annotations, constancy, execution, optimization, syntax, or transformations are outside the scope of the present invention. Therefore, with a proper understanding of the present disclosure, ambiguity, pure abstraction, missing technical features, and the attendant verification problems are also avoided.

[0025] More generally, those skilled in the art will recognize that not every part of this disclosure, or any specific detail therein, is required to satisfy legal standards such as enabling, written description, or best mode. Moreover, embodiments are not limited to the particular converters, software development environments, programming languages, syntax diagram examples, development tools, identifiers, files, data structures, notations, control flow, pseudocode, or other implementation choices described herein. Any apparent conflict with any other patent disclosure (even from the owner of the present invention) has no role in interpreting the claims presented in this patent disclosure.

[0026] Technical characteristics

[0027] The technical features of the embodiments described herein will be apparent to those skilled in the art and will also be apparent to a wide range of interested readers in several ways. Some embodiments address technical activities such as code optimization and code conversion from one form (e.g., source code in a high-level programming language or assembly language) to another form (e.g., assembly language or byte code or p-code or machine code), which are activities well known in computing technology. Some of the technical mechanisms discussed include, for example, syntax graphs, algorithms for traversing syntax graphs, syntax subgraph structures, algorithms for identifying syntax subgraph structures, optimization directories, algorithms for using or updating entries in optimization directories, various hash values, and optimization feature annotations (which are data structures or portions thereof). Some of the technical effects discussed include, for example, optimized code implemented by replacing code with constants (i.e., constant merging), stored data, stored instructions, and annotations stored in, for example, source code, converter output, or optimization directories, providing persistence of semantic information about optimization opportunities. Thus, purely psychological processes are excluded. Some embodiments improve the operation of computing systems by making code optimization more practical. Based on the description provided, other advantages of the technical features taught will also be apparent to those skilled in the art.

[0028] Acronyms, abbreviations, names and symbols

[0029] Some abbreviations, abbreviations, names and symbols are defined below. Other abbreviations, abbreviations, names and symbols are defined elsewhere in this document or do not need to be defined here so that those skilled in the art will understand.

[0030] ALU: Arithmetic and Logic Unit

[0031] API: Application Programming Interface

[0032] BIOS: Basic Input / Output System

[0033] CD: compact disc

[0034] CPU: Central Processing Unit

[0035] DVD: Digital Versatile Disc or Digital Video Disc

[0036] FPGA: Field Programmable Gate Array

[0037] FPU: Floating Point Processing Unit

[0038] GPU: Graphics Processing Unit

[0039] GUI: Graphical User Interface

[0040] IaaS or IAAS: Infrastructure as a Service

[0041] ID: identification or identity

[0042] IDE: Integrated Development Environment, sometimes also called "Interactive Development Environment"

[0043] IDS: Interference Detection System, which may be or include, for example, a HIDS (Host-based IDS) or a NIDS (Network-based IDS)

[0044] IoT: Internet of Things

[0045] IP: Internet Protocol

[0046] LAN: Local Area Network

[0047] OS: operating system

[0048] PaaS or PAAS: Platform as a Service

[0049] RAM: Random Access Memory

[0050] ROM: Read-Only Memory

[0051] UEFI: Unified Extensible Firmware Interface

[0052] VM: Virtual Machine

[0053] WAN: Wide Area Network

[0054] Some additional terms

[0055] Reference is made herein to exemplary embodiments, such as those illustrated in the drawings, and specific language is used herein to describe the same. However, alterations and further modifications of the features described herein, as well as additional technical applications of the abstract principles described herein, which would occur to one skilled in the relevant art and which have all of the present disclosure, are deemed to be within the scope of the claims.

[0056] The meaning of the terms is set forth in this disclosure, so these should be carefully noted when reading the claims. Specific examples are given, but it will be understood by those skilled in the relevant art that other examples may also fall within the meaning of the terms used and within the scope of one or more claims. The terms do not necessarily have the same meaning as they do in general use (particularly, in non-technical use) or in specific industrial use or in a specific dictionary or dictionary collection. Figure numbers can be used with various phrases to help show the breadth of the terms. The omission of a figure number for a given paragraph of text does not necessarily mean that the text does not discuss the content of the figure. The inventors claim and exercise the right to specific and selected lexicography. The referenced terms are explicitly defined, but terms can also be implicitly defined without the use of reference marks. Terms can be defined explicitly or implicitly, herein in the specific embodiments and / or elsewhere in the application documents.

[0057] As used herein, a "computer system" (also referred to as a "computing system") may include, for example, one or more servers, motherboards, processing nodes, laptops, tablet computers, personal computers (portable or non-portable), personal digital assistants, smartphones, smart watches, smart bracelets, mobile phones or mobile phones, other mobile devices having at least a processor and memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, and / or other devices that provide one or more processors controlled at least in part by instructions. The instructions may be in the form of firmware or other software in memory and / or dedicated circuitry.

[0058] A "multi-threaded" computer system is a computer system that supports multiple threads of execution. The term "thread" should be understood to include code that can or is subject to scheduling and possibly synchronization. For example, a thread may also be referred to outside of this disclosure as another name, such as a "task," "procedure," or "co-routine." However, a distinction is made herein between threads and processes because a thread defines the execution path within a process. In addition, the threads of a process share a given address space, while different processes have different corresponding address spaces. The threads of a process can run sequentially in parallel or combine parallel execution and sequential execution (e.g., time slicing).

[0059] A "processor" is a thread-processing unit, such as a core in a simultaneous multithreading implementation. A processor comprises hardware. A given chip can house one or more processors. Processors can be general-purpose or specialized for specific purposes, such as vector processing, graphics processing, signal processing, floating-point arithmetic processing, encryption, I / O processing, machine learning, and so on.

[0060] The "kernel" includes the operating system, hypervisor, virtual machine, BIOS or UEFI code, and similar hardware interface software.

[0061] "Code" refers to processor instructions, data (which includes constants, variables, and data structures), or both instructions and data. "Code" and "software" are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code.

[0062] "Program" is used broadly herein to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (also called developers) and / or automatically generated.

[0063] "Service" means a consumable program offering in a cloud computing environment or other network or computing system environment that provides resources or access to resources to multiple programs.

[0064] "Cloud" refers to pooled resources for computing, storage, and networking that are elastically available as measured, on-demand services. Clouds can be private, public, community, or hybrid, and cloud services can be provided as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), or another service. Unless otherwise specified, discussions of reading from or writing to files include reading / writing local files or reading / writing over a network, which can be a cloud network or another network, or both (local and networked read / write).

[0065] "IoT" or "Internet of Things" refers to any networked collection of addressable embedded computing nodes. Such a node is an example of a computer system as defined herein, but it also has at least two of the following characteristics: (a) no local human-readable display; (b) no local keyboard; (c) the primary source of input is a sensor that tracks a source of non-verbal data; (d) no local rotating disk storage—RAM chips or ROM chips provide only local memory; (e) no CD or DVD drive; (f) embedded in a household appliance or household device; (g) embedded in an implantable or wearable medical device; (h) embedded in a vehicle; (i) embedded in a process automation control system; or (j) a design focused on at least one of the following: environmental monitoring, municipal infrastructure monitoring, industrial equipment monitoring, energy usage monitoring, human or animal health monitoring, physical security, or physical transportation system monitoring. IoT storage devices can be the target of unauthorized access attempts via the cloud, via another network, or via direct local access.

[0066] As used herein, "comprising" allows for additional elements (ie, including means comprising) unless stated otherwise.

[0067] "Optimization" means improvement, not necessarily perfection. For example, further improvements may be possible in an already optimized program or algorithm.

[0068] "Process" is sometimes used herein as a term in the field of computing science and includes resource users in this technical sense, i.e., for example, co-routines, threads, tasks, interrupt handlers, application processes, kernel processes, programs, and target methods. "Process" is also used herein as a patent law field term, for example to describe a process claim relative to a system claim or a product (configured storage medium) claim. Similarly, "method" is sometimes used herein as a technical term in the field of computing science (a type of "routine") and also as a patent law field term ("process"). "Process" and "method" in the patent law sense are used interchangeably herein. Those skilled in the art will understand which meaning is intended in a particular case, and will also understand that a given required process or method (in the patent law sense) can sometimes be implemented using one or more processes or methods (in the computing science sense).

[0069] "Automatically" means by using automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein), as opposed to without automation. Specifically, steps performed "automatically" are not performed by handwriting or human thought, but may be initiated by a human or directed interactively by a human. Automatic steps are performed using a machine to achieve one or more technical effects that would not be achieved without the technical interaction provided thereby.

[0070] Those skilled in the art understand that technical effects are the assumed purpose of technical embodiments. For example, the mere fact that in an embodiment, calculations are involved and some calculations can also be performed without technical components (e.g., by paper and pen, or even as a mental step) does not remove the existence of technical effects or change the concrete and technical nature of the embodiments. The operations discussed, such as automatically traversing at least a portion of a syntax graph, identifying subgraph structures in a syntax graph, annotating a syntax graph, assessing optimization catalogs, calculating hash values, rewriting syntax graphs, storing code, and many other operations are understood herein as inherently digital. The human mind cannot be directly connected to a CPU or other processor, or to RAM or other digital storage, to read and write the necessary data to perform the code conversion optimization steps taught herein. This will all be clearly understood by those skilled in the art in view of this disclosure, but others may sometimes need to be informed or reminded of the facts.

[0071] "Computationally" also means that a computing device (at least a processor plus memory) is being used, and excludes obtaining a result solely through human thought or solely through human action. For example, as understood herein, performing arithmetic with pen and paper is not performing arithmetic computationally. The computational results are faster, broader, deeper, more accurate, more consistent, more comprehensive, and / or otherwise provide a technical effect that is beyond the scope of human performance alone. A "computational step" is a step that is computationally performed. Neither "automatically" nor "computationally" necessarily means "immediately." "Computationally" and "automatically" are used interchangeably herein.

[0072] "Actively" means without direct request from the user. In fact, the user may not even be aware that an active step is possible through an embodiment until the results of the step are presented to the user. Unless otherwise stated, any calculation and / or automatic step described herein may also be performed actively.

[0073] Throughout this document, the use of the optional plural "(s)" means that there are one or more of the indicated features. For example, "processor(s)" means "one or more processors" or equivalently "at least one processor."

[0074] For purposes of U.S. law and practice, use of the word "step" herein, in the claims or elsewhere, is not intended to invoke means-plus-function, step-plus-function, or 35 U.S.C. 112, paragraph 6 / section 112(f) claim descriptions. Any assumption to that effect is hereby expressly disclaimed.

[0075] For purposes of U.S. law and practice, claims are not intended to invoke means-plus-function interpretation unless they use the phrase “means for.” Claim language intended to be interpreted as means-plus-function language, if any, will expressly recite that intent through the use of the phrase “means for.” When means-plus-function interpretation applies, whether through the use of “means-plus-means” and / or through legal interpretation of the claim language, the means recited in the specification for a given noun or a given verb should be understood to be linked to the claim language and linked together herein by any of the following: appearance within the same block in a frame of a figure, representation by the same or similar name, representation by the same reference numeral, a functional relationship depicted in any of the figures in the figures, or a functional relationship noted in the text of the disclosure. For example, if a claim limitation recites "zac widget" and the patent claim limitation becomes subject to a means-plus-function interpretation, then at least all structure identified anywhere in the specification in any figure, paragraph, or example that mentions "zac widget," or is tied together by any reference numerals assigned to zac widget, or is disclosed as having a functional relationship to the structure or operation of zac widget, will be considered part of the structure identified in an application for zac widget and will help define an equivalent set for zac widget structure.

[0076] Those skilled in the art will recognize that this innovative disclosure discusses various data values and data structures, and recognizes that such items reside in memory (RAM, disk, etc.), thereby configuring the memory. Those skilled in the art will also recognize that this innovative disclosure discusses various arithmetic steps that are embodied in executable code in a given implementation, and that such code also resides in memory, and that it effectively configures any general-purpose processor that executes it, thereby transforming it from a general-purpose processor into a special-purpose processor that is functionally dedicated hardware.

[0077] Therefore, those skilled in the art will not make the mistake of considering the following as non-overlapping items (a) the memory described in the claims, and (b) the data structure or data value or code described in the claims. Data structures and data values and code are understood to be resident in the memory, even if the claims do not clearly describe the residence of each and all data structures or data values or code segments mentioned. Therefore, there is no need for such a clear description of residence. However, it will not be prohibited, and there can be one or two selected descriptions for strength, thereby not excluding all other data values and data structures and codes from residence. Similarly, the code functionality described in the claims is understood to configure the processor, regardless of whether the claims clearly describe this configuration quality.

[0078] Throughout this document, unless expressly stated otherwise, any reference to a step in a process assumes that the step may be performed directly by the relevant party and / or indirectly by the party via an intermediary and / or intermediate entity and still fall within the scope of the step. That is, direct performance of the step by the relevant party is not required unless direct performance is an expressly stated requirement. For example, steps involving actions by a relevant party regarding a destination or other subject (such as accessing, annotating, ascertaining, assigning, associating, compiling, consulting, disabling, identifying, enabling, enhancing, entering, evaluating, executing, finding, hashing, identifying, including, indicating, inserting, calling, listing, matching, memoizing, naming, optimizing, passing, executing, prioritizing, generating, identifying, recompiling, reducing, relying on, replacing, rewriting, saving, scanning, triggering, converting, traversing, triggering, updating (as well as accesses / accessed, annotates / annotated, etc.)) may involve intermediate actions by some other party (such as forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, verifying, calling, etc.), including any actions recorded herein, but are still understood to be performed directly by the relevant party.

[0079] Whenever reference is made to data or instructions, it should be understood that these items configure computer-readable memory and / or computer-readable storage media, thereby transforming them into something specific in the human mind as opposed to existing only on paper, or, for example, as a signal propagating only online. For the purposes of U.S. patent protection, in the United States Patent and Trademark Office (USPTO) case In re Nuijten, memory or other computer-readable storage media is not a propagated signal or carrier wave or pure energy outside the scope of patentable subject matter. No claim in the United States covers the signal itself or pure energy, and any claim interpretation that asserts otherwise is prima facie unreasonable in light of this disclosure. Unless otherwise expressly stated in a claim granted outside the United States, the claim does not cover the signal itself or pure energy.

[0080] Furthermore, despite anything that appears to be to the contrary elsewhere herein, a clear distinction will be understood between (a) computer-readable storage media and computer-readable memory, on the one hand, and (b) transmission media, also known as signal media, on the other hand. Transmission media are propagating signals or carrier wave computer-readable media. In contrast, computer-readable storage media and computer-readable memory are not propagating signals or carrier wave computer-readable media. Unless otherwise expressly stated in the claims, "computer-readable medium" refers to computer-readable storage media, not the propagating signal itself and not pure energy.

[0081] The "embodiments" herein are examples. The term "embodiments" is not interchangeable with "the present invention." The embodiments may freely share or borrow aspects to create other embodiments (provided the results are operable), even if the resulting combinations of aspects are not themselves explicitly described herein. Requiring each and all permitted combinations to be explicitly and individually described would be unnecessary for one skilled in the art and would be contrary to the strategy of identifying patent specifications written for readers who are skilled in the art. Formal combinatorial calculations and informal general perceptions of the large number of possible combinations arising from even a small number of combinable features would also indicate that a large number of aspect combinations exist for the aspects described herein. Therefore, requiring explicit recitation of each and all combinations would be contrary to the strategy of requiring patent specifications to be concise and requiring readers to be knowledgeable in the technical field of interest.

[0082] Reference Number List

[0083] The following list is provided for convenience and to support the drawings and is part of the text of the specification, which describes the innovation by reference to a number of items. However, items not listed here may be part of a given embodiment. For better readability of the text, a given reference number is described close to some, but not all, of the referenced items in the text. The same reference number may be used to refer to different examples or different instances of a given item. The list of reference numbers is as follows:

[0084] 100 Operating Environment, also known as Computing Environment

[0085] 102 Computer system, also known as operating system or computing system

[0086] 104 users

[0087] 106 Peripheral Devices

[0088] 108 Networks in general, including, for example, LANs, WANs, software-defined networks, clouds, and other wired and wireless networks

[0089] 110 processors

[0090] 112 Computer-readable storage media, such as RAM, hard disk

[0091] 114 Removable computer readable storage medium

[0092] 116 Instructions executable by a processor; may be on a removable storage medium or in other memory (volatile or non-volatile or both)

[0093] 118 data

[0094] 120 (multiple) cores, e.g., (multiple) operating systems, BIOS, UEFI, device drivers

[0095] 122 Tools, such as antivirus software, firewalls, packet sniffer software, interference detection systems, interference prevention systems, debuggers, profilers, compilers, interpreters, software development tools and toolkits, hardware development tools and toolkits, diagnostic

[0096] 124 applications, such as word processors, web browsers, spreadsheets, games, and email tools

[0097] 126 Display screen, also known as "monitor"

[0098] 128 Computing hardware, not otherwise associated with reference numerals 106, 108, 110, 112, 114

[0099] 202 Code Conversion Environment

[0100] 204 Conversion program; can be part or all of the core 120, tool 122, application 124 or other software

[0101] 206 Transformer (e.g., compiler or interpreter) that optimizes functionality using code transformation (e.g., combining Figure 4 、 Figure 6 、 Figure 7 、 Figure 8 、 Figure 11 、 Figure 12 or Figure 13 206 also refers to the computing system 102, using code conversion to optimize the functional configuration

[0102] 208 Code conversion, that is, the output from the converter 206

[0103] 210 Optimized program code

[0104] 212 optimizes the directory; can be updated by the converter 206; 212 refers not only to the data stored in the directory entry 602 but also to the API or other interface software that helps maintain the directory data and provides access to the directory data 602

[0105] 214 Generally optimized or non-optimized code

[0106] 216 Generally commented or non-commented source code

[0107] 302 Cloud; also known as "Cloud Computing Environment"

[0108] 304 virtual machine, for example, a computing construct that provides hardware virtualization and includes an operating system; although container 308 differs from a virtual machine with respect to the inclusion of a guest operating system, for the purposes of this disclosure, containers and virtual machines are functionally similar because both can run a translator 206 and both run as code that can be optimized by an appropriate translator 206, so any reference to a virtual machine also refers to a container unless otherwise indicated.

[0109] 306 Integrated Development Environment

[0110] 308 Containers, i.e., computing constructs that provide user space virtualization and do not themselves include an operating system

[0111] 402 Optimization features, such as whether code can (or does) have side effects when executed, whether code can (or does) access non-local variables when executed, etc.; these and other examples of optimization features are described in Figure 8 Description (which is not necessarily exhaustive for a given embodiment)

[0112] 404 Optimization Feature Annotation, i.e., a data structure indicating an optimization feature (which can be as simple as a bit flag or an enumeration value or other data value)

[0113] 406 Graph Annotator, i.e., code that annotates syntax graphs with optimization feature annotations at execution time

[0114] 408 Program 204 code 214, corresponding to comment 404 in the syntax diagram

[0115] 410 Syntax Graph; As used herein, a "syntax graph" is a graphical data structure that represents at least the grammatical structure of at least a portion of program 204; a syntax graph may also represent data type information for a program; some examples of syntax graphs include abstract syntax trees (ASTs) and parse trees; trees and directed acyclic graphs (DAGs) are some examples of graphs.

[0116] 412 syntax graph walker, i.e., code that walks the syntax graph when executed; unless otherwise specified, the traversal is performed in a bottom-up manner in the tree portion of the syntax graph, for example using a depth-first search

[0117] 414 Syntax graph node, i.e., a data structure that contains syntax information and has a position in the syntax graph; a position can be defined by the node's connection(s) to(s) other nodes of the syntax graph; a syntax graph is a directed graph, i.e., any two given syntax graph nodes that are directly connected to each other have a parent-child relationship, unless otherwise stated.

[0118] 416 Connections between nodes 414; the connections may be implemented as, for example, pointers or indexes that explicitly identify the nodes of the connection and also explicitly or implicitly indicate which node is the parent node or which node is the child node

[0119] 418 Syntax subgraph structure, such as a syntax graph subtree representing a binary operator and its operands, or a syntax graph subtree representing a function call in which parameters are passed by reference rather than by value, or a syntax graph subtree representing a try-catch exception handling code segment, or a syntax graph subtree representing a constant value, or another syntax subgraph structure representing code that has an execution value or some aspect of its execution effect discernible at execution time before execution. 502

[0120] 420 Syntax subgraph structure identifier, i.e., code that identifies a predefined syntax graph subgraph structure when executed; identification may be accomplished, for example, by comparing a hash or vectorized or other representation of a portion of a syntax graph with entries in an optimization directory

[0121] 422 is generally a user interface; for example, it may include a graphical user interface (GUI) or an application program interface (API) or both.

[0122] 424 is generally an optimizer; 424 also refers to a pluggable implementation of an optimizer; an optimizer is a code that takes a code segment X or its representation as input and produces an optimized code X' or its representation as output at execution time.

[0123] 426 Syntax Graph Rewriter

[0124] 502 Aspects of the code related to conversion time optimization

[0125] 504 A value performed or produced by code during its execution

[0126] 506 may execute the definition of value 504

[0127] 508 Effects of the execution of code, such as side effects of a function, or changes to variables external to the code but accessed by the executing code, or exceptions caused by the executing code; 508 also refers to the invalidity of the execution of the code, such as the absence of any side effects of a function, or the absence of any changes to variables external to the code, or the absence of specific exceptions from the execution of the code

[0128] 602 Optimize entries in the directory

[0129] 604 Identification of a subgraph structure suitable for use in optimizing directory entries; also refers to the act of identifying a subgraph structure or subgraph structure template

[0130] 702 Code library capable of being dynamically linked in an executable program, linked by a linker, or otherwise included in an executable program

[0131] 704 is generally a routine, such as a function, procedure, handler, or another code segment that is parameterizable or callable or both

[0132] 706 The name of the routine

[0133] 708 Routine 704, which is part of library 702 and is therefore configured for use by multiple programs (different programs may share a single copy of the routine, or they may have respective copies of the routine)

[0134] 710 Routine 704, dedicated to a specific program, not a library routine

[0135] 712 is usually a hash value

[0136] 714 hash value of routine 704; routines that differ in their parameters or their bodies will have different hash values; for example, a given implementation may compute the hash value of a routine based on the routine's source code or based on a syntax diagram representation of the routine, or both

[0137] 716 Hash value of subgraph structure 418; subgraph structures with different numbers and types of nodes 414 will have different hash values

[0138] 718 Subgraph structure templates, i.e., data structures that generalize a set of subgraph structures by replacing details with placeholders, such as constant placeholders instead of specific constants, or parameter lists that are placeholders for a specific number and order of routine parameters

[0139] 720 Hash value of the subgraph structure template; subgraph structure templates with different numbers and types of nodes 414 will have different hash values

[0140] 802 Optimizing the functionality of values in property annotations

[0141] 804 Optimize the value in the property annotation

[0142] 806 indicates semantic information about the side effects of executing program code; 806 refers to the action of indicating (verb) and also refers to indicating (noun)

[0143] 808 Side effects of code; A side effect of a routine is any change in program state caused by the execution of the routine other than the return value of a function, or a change in state caused by the return value of a function, for example, a side effect occurs when a function sets a global variable and then returns a value.

[0144] 810 indicates semantic information about non-local variable access through program code; 810 refers to the action of indicating (verb) and also refers to indicating (noun)

[0145] 812 Non-local variables; 812 also refers to actions that access non-local variables

[0146] 814 indicates semantic information about local static variables accessed through program code; 814 refers to the action of indicating (verb) and also refers to indicating (noun)

[0147] 816 Local static variables; 816 also refers to the action of accessing local static variables

[0148] 818 indicates semantic information about passing a parameter to a routine's program code by reference rather than by value; 818 refers to the action of indicating (verb) and also refers to indicating (noun)

[0149] 820 Parameters passed to a routine by reference; 820 also refers to the act of passing a parameter to a routine by reference

[0150] 822 indicates semantic information about program code using an I / O device or an I / O stream or both; 822 refers to the action of indicating (verb) and also refers to indicating (noun)

[0151] 824 Use of an I / O device or an I / O stream or both; 824 also refers to the action of using an I / O device or an I / O stream or both, and refers to an I / O device or an I / O stream or both; some examples include reading from a file, even if the file is empty or static

[0152] 826 indicates semantic information about program code that raised an exception during execution; 826 refers to the action of indicating (verb) and also refers to indicating (noun)

[0153] 828 exceptions, such as overflow, attempted division by zero, attempted out-of-bounds access, and invalid pointer; 828 also refers to the action that caused the exception

[0154] 830 indicates semantic information about program code that failed to terminate during execution of a program containing the code; 830 refers to the action of indicating (verb) and also refers to indicating (noun)

[0155] 832 termination of a code segment, such as by passing control to another code segment in the program or passing control back to the core, at which point the program runs; when the context of a reference number states "non-" or "failure" with respect to termination, "non-termination" may also be referred to by 832

[0156] 900 Optimization

[0157] 902 Processor Cycle Reduction

[0158] 904 Reduction in memory size; can refer generally to RAM size, or to a specific portion of RAM, such as the heap, or to on-disk memory

[0159] 906 Reduction of I / O Operations

[0160] 908 Constant merging

[0161] 910 Exception Handler

[0162] 912 Reduced use of exception handlers

[0163] 914 Memoization, e.g., storing the result of a calculation for a particular input to a routine, recognizing that the same input has been supplied again in a subsequent call to the routine, and then returning the stored result rather than re-executing the routine to recalculate the same result value

[0164] 1200 Flowchart; 1200 also refers to Figure 12 Flowchart description or Figure 12 process Figure 1 A consistent code conversion optimization method

[0165] 1202 For example, by executing the traverser 412 to traverse the syntax graph

[0166] 1204 Scanning the syntax graph for matching subgraph structures, for example by computing or comparing hashes or node vectorization

[0167] 1206 Ascertain the presence of an optimization feature, for example by identifying a match between a subgraph structure and an entry in the directory 212 or inferring the presence of a feature at a parent node through an optimization feature annotation at a child node.

[0168] 1208 Identifying matches between subgraph structures and directory 212 entries, for example by comparing hashes or comparing vectorizations using a similarity metric

[0169] 1210 The presence of a property at the parent node is inferred by the optimization property annotations of the child nodes. For example, if all child nodes are pure in the sense that they do not raise any exceptions, then the parent node of their corresponding code (e.g., code implementing a binary operator) is inferred to have the same purity.

[0170] 1212 Annotate a syntax diagram node by associating a comment 404 with the node (thus, annotate the syntax diagram itself)

[0171] 1214 associates the annotation 404 with the node, for example by setting a bit flag or an enumeration value or list pointer in a data structure that implements the node; 1214 may also refer to the association of the node 408 with a portion of the syntax diagram.

[0172] 1216 Perform optimizations, such as by rewriting syntax graphs or merging constants, or by generating different bytecodes or machine code without breaking the program

[0173] 1218 Generate optimized code by generating optimized byte code or machine code or other executable code 210 without breaking the program

[0174] 1300 Flowchart; 1300 also refers to Figure 13 Flowchart (which incorporates Figure 12 Steps) instructions or with Figure 13 process Figure 1 A consistent code conversion optimization method

[0175] 1302 Transforming code, such as compiling code or interpreting code; compilation can be ahead-of-time (AOT) or just-in-time (JIT).

[0176] 1304 exists prior to the event, e.g., the catalog 212 may exist before a compilation attempt; indeed, the catalog may exist prior to the creation of some or all of the source code for the program, which is subsequently optimized based in part on matching entries 602 of the catalog.

[0177] 1306 exists after an event, for example, directory 212 may exist even after compilation is complete, whereas strictly speaking, once compilation is complete, the internal data structures within the optimizing compiler cease to exist effectively and the compiler process releases the memory it used while it was running.

[0178] 1308 indicates a discernible aspect of the code or a syntax diagram representation of the code; some examples of the indication 1308 are shown in Figure 8 and designated at 806, 810, 814, 818, 822, and 826

[0179] 1310 execution of a program; may be referred to as "running" a program; 1310 also refers to the act of at least partially executing a program

[0180] 1312 Identify (verb) item; may also refer to Identify (noun)

[0181] 1314 identifies an example of 1312 involving the use of an offset or pointer or other index in an array, list, map, database, or other data structure; 1314 also refers to an index

[0182] 1316 Enable use of plugins or other code snippets

[0183] 1318 Disable the use of plugins or other code snippets

[0184] 1320 Recompiling previously compiled program code after changing configuration files, make files, or other settings that alter program functionality

[0185] 1322 Optimize feature subtree

[0186] 1324 A location in a syntax diagram, such as a specific node or set of nodes

[0187] 1326 Matches a program's code or a portion of a program's syntax graph (i.e., a subgraph) to a directory entry's subgraph structure identifier.

[0188] 1328 Provide optimizer with access to syntax graph

[0189] 1330 Generate optimization candidates, i.e., possible optimizations in a given situation

[0190] 1332 Assigning relative weights to optimization candidates

[0191] 1334 Optimize the relative weight of candidates

[0192] 1336 Prioritizing optimization candidates for actual implementation based at least in part on their relative weights

[0193] 1338 Rewrite part of the syntax graph (e.g., ) to perform constant merging optimization

[0194] 1340 Insert callbacks in syntax diagrams or in code generated from syntax diagrams

[0195] 1342 callback routine; also referred to as "callback" for short

[0196] 1344 Call callback; also known as call callback

[0197] 1346 Triggering partial evaluation of executable code

[0198] 1348 Partial Evaluation of Executable Code

[0199] 1350 Avoid relying on keywords in source code to indicate 1308 discernible aspects

[0200] 1352 Programming language keywords, for example, C++ constant expression keywords

[0201] 1354 For example, by searching the directory to consult the directory 212

[0202] 1356 Update directory 212, for example, by adding an entry 602, modifying an entry 602, deleting an entry 602, or changing the order of the entries 602

[0203] 1358 For example, by inferring the purity (or lack of purity) of a child node to be pure (or impure), forming a property subtree

[0204] 1360 Locate (i.e., find) a property subtree in a syntax diagram

[0205] 1362 Enhance source code by adding comment 404

[0206] 1364 Save comments or annotated syntax diagrams in a file

[0207] 1366 files

[0208] 1368 Any step discussed in this disclosure that has not been assigned some other reference number

[0209] 1370 Optimization candidates, i.e., optimizations that could be performed but have not yet been performed

[0210] Operating Environment

[0211] refer to Figure 1 , an operating environment 100 for an embodiment includes at least one computer system 102. Computer system 102 may or may not be a multi-processor computer system. The operating environment may include one or more machines in a given computer system, which may be clustered in a cloud, client-server networked, and / or peer-to-peer networked. An individual machine is a computer system, and a group of cooperating machines is also a computer system. A given computer system 102 may be configured for end users using applications, for administrators, as a server, as an assigned processing node, and / or in other ways.

[0212] Human users 104 can interact with computer system 102 via typed text, touch, voice, movement, computer vision, gestures, and / or other forms of I / O using a display, keyboard, and other peripherals 106. Screen 126 can be a removable peripheral 106 or an integral part of system 102. A user interface can support interaction between an embodiment and one or more human users. The user interface can include a command line interface, a graphical user interface (GUI), a natural user interface (NUI), a voice command interface, and / or other user interface (UI) presentations, which can be presented as different options or can be integrated.

[0213] System administrators, network administrators, cloud administrators, security analysts and other security personnel, operations personnel, developers, testers, engineers, auditors, and end users are each specific types of users 104. Automated agents, scripts, playback software, devices, and the like that act on behalf of one or more individuals may also be users 104, for example, to facilitate testing of system 102. Storage devices and / or network devices, depending on their removability from processor 110, may be considered peripherals in some embodiments and part of system 102 in other embodiments. Figure 1 Other computer systems not shown may interact with computer system 102 by technical means, or with another system embodiment using one or more connections to network 108 via network interface equipment, for example.

[0214] Each computer system 102 includes at least one processor 110. As with other suitable systems, the computer system 102 also includes one or more computer-readable storage media 112. The storage media 112 can be of different physical types. The storage media 112 can be volatile memory, non-volatile memory, locally fixed media, removable media, magnetic media, optical media, solid-state media, and / or other types of physically durable storage media (as opposed to merely propagating signals or pure energy). Specifically, a configured storage medium 114 (such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile storage medium) can functionally become a part of the computer system when inserted or otherwise installed, allowing its contents to interact with and be used by the processor 110. Removable configured storage media 114 is an example of a computer-readable storage medium 112. Some other examples of computer-readable storage media 112 include built-in RAM, ROM, hard drives, and other memory storage devices that are not easily removable by the user 104. For purposes of compliance with current US patent requirements, under any claim pending or issued in the United States, neither the computer-readable medium, computer-readable storage medium, nor computer-readable memory is a signal per se or pure energy.

[0215] Storage medium 114 is configured with binary instructions 116 executable by processor 110; "executable" is used broadly herein to include, for example, machine code, interpretable code, bytecode, and / or code running on a virtual machine. Storage medium 114 is also configured with data 118, which is created, modified, referenced, and / or otherwise used for the technical effects of executing instructions 116. Instructions 116 and data 118 configure the memory or other storage medium 114 in which they reside; when memory or other computer-readable storage medium is a functional part of a given computer system, instructions 116 and data 118 also configure that computer system. In some embodiments, a portion of data 118 represents real-world items, such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, and the like. Such data is also transformed through backup, restore, submission, abort, reformatting, and / or other technical operations.

[0216] A given operating environment 100 may include an integrated development environment (IDE) 122, 306 that provides developers with a set of collaborative computing technology development tools 122, such as compilers, interpreters, decompilers, assemblers, disassemblers, source code editors, profilers, debuggers, simulators, fuzz testers, repository access tools, version control tools, optimizers, collaboration tools, etc. In particular, some suitable operating environments for some software development embodiments include or facilitate the creation of an IDE that is configured to support program development. Visual Development Environment (Microsoft Corporation logo). Some suitable operating environments include environments (a trademark of Oracle America, Inc.), and some include environments that utilize languages such as C++ or C# ("C-Sharp"), but many of the teachings herein are applicable to a wide variety of programming languages, programming models, and programs.

[0217] Although the embodiments can be described as being implemented as software instructions executed by one or more processors in a computing device (e.g., a general-purpose computer, a server, or a cluster), such description is not meant to exhaust all possible embodiments. It will be understood by those skilled in the art that it is generally also possible to implement the same or similar functionality directly in hardware logic in whole or in part to provide the same or similar technical effects. Alternatively, or in addition to software implementations, the technical functionality described herein can be performed at least in part by one or more hardware logic components. For example, and without excluding other implementations, the embodiments may include hardware logic components 110, 128, such as field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chip components (SOCs), complex programmable logic devices (CPLDs), and similar components. The components of the embodiments may be grouped into interactive functional modules based on, for example, their inputs, outputs, and / or their technical effects.

[0218] In addition to the processor 110 (e.g., CPU, ALU, FPU and / or GPU), memory / storage medium 112 and display 126, the operating environment may also include other hardware 128, such as, for example, a battery, bus, power supply, wired and wireless network interface cards. The terms "screen" and "display" are used interchangeably herein. The display 126 may include one or more touch screens, a screen that responds to input from a pen or stylus, or a screen that operates only for output. In some embodiments, peripheral devices 106 such as human user I / O devices (screen, keyboard, mouse, stylus, microphone, speaker, motion sensor, etc.) will exist in operable communication with one or more processors 110 and memory.

[0219] In some embodiments, the system includes multiple computers connected by a wired and / or wireless network 108. The networking interface equipment 128 can provide access to the network 108 using network components such as packet-switched network interface cards, wireless transceivers, or telephone network interfaces that may be present in a given computer system. Virtualization of the networking interface equipment and other network components, such as switches or routers or firewalls, can also exist (for example) in a software-defined network or sandbox or other secure cloud computing environment. A given embodiment can also communicate technical data and / or technical instructions via direct memory access, removable non-volatile storage media, or other information storage, retrieval, and / or transmission pathways.

[0220] Those skilled in the art will appreciate that the foregoing and other aspects presented herein in the context of an “operating environment” may form part of a given embodiment. The headings herein are not intended to provide a strict classification of features into embodiment and non-embodiment feature sets.

[0221] One or more items are shown in outlines in the figures, or listed in brackets, to emphasize that they are not a necessary part of the illustrated operating environment or all embodiments, but may interoperate with the operating environment or items in some embodiments as discussed herein. Items that are not outlined or in brackets are not necessarily required in any figure or any embodiment. Specifically, Figure 1 It is provided for convenience; Figure 1 The inclusion of an item does not imply that the item was known prior to the current innovation or that use of the item described was available.

[0222] More about the system

[0223] refer to Figures 1 to 11 , some embodiments use or provide a functionality-enhanced system 206. The functionality enhancement facilitates code optimization by providing technical mechanisms that can (a) make code optimization opportunities more visible to developers, such as as annotations 404 in a catalog or source code, and (b) make code optimization opportunities persist outside the inner workings of the compiler, such as as an annotated syntax diagram that is provided as compiler output and reusable as input to subsequent compilations.

[0224] Figure 2 The enhanced translator 206 is shown in the translation environment 202. The program 204 fed into the enhanced translator 206 produces optimized program code 210 as output and may also produce or update an optimization catalog 212 as output. That is, the translation 208 need not be limited to machine code or byte code, but in some embodiments may also include continuous optimization feature annotations 404 in the form of, for example, the catalog 212 or annotated source code 216.

[0225] Figure 3 Some examples of conversion environments 202 are shown. The listed examples include network 108, cloud 302, virtual machine 304 or container 308, and integrated development environment 306. However, those skilled in the art will recognize that converter 206 can also run in other environments, and some of these environments can overlap, for example, virtual machine 304 can reside in cloud 302.

[0226] Figure 4The diagram illustrates an enhanced transcoder 206 in the form of a system 102 with enhanced functionality for transcoding optimization. In this example, the enhanced functionality includes a graph annotator 406, which is invoked or coordinated with a syntax graph traverser 412 and a subgraph structure identifier 420. The syntax graph traverser 412 traverses the connections 416 of nodes 414 in a syntax graph 410, which is a parse tree, abstract syntax tree, or similar representation of the structure of some program 204 code 214. The subgraph structure identifier 420 identifies certain subgraph structures 418 in the syntax graph 410, namely, subgraph structures 418 that have optimization properties 402 (discernible traits), such as the absence of side effects, restrictions on runtime exceptions, and the absence of local static variables or reference parameters. The discernible absence of such traits is also considered an optimization property 402. The graph annotator 406 places optimization property annotations 404 in the syntax graph 410 accordingly. Annotation 404 may then be used by optimizer 424 , which is part of or coordinated with translator 206 , to perform code optimization during code conversion by merging code 408 into constants.

[0227] Figure 5 Some aspects 502 of code 214 are shown in the form of two categories of discernible optimization characteristics 402. One category involves specific execution values 504 discernible before execution, or a definition 506 of an execution value 504 discernible before execution. For example, the enhanced converter can discern from the syntax diagram that a certain Boolean expression will always evaluate to true 504 when executed, or a definition 506 of an arithmetic expression that will always produce a non-zero value 504 when executed. Another category of optimization characteristics 402 includes execution effects 508 or non-effects 508. For example, the enhanced converter can use the syntax diagram to discern that a certain code segment 408, 214 may raise a divide-by-zero exception, and that another code segment 408, 214 is a pure function (e.g., like sin(x)) without any side effects.

[0228] Figure 6An entry 602 in an optimization catalog 212 is illustrated. The example shown includes an identification 604 of a syntax subgraph structure 418 and a corresponding optimization property annotation 404. For example, entry 602En may identify a subgraph structure 418 that matches a division operator and includes an annotation 404 indicating that a divide-by-zero exception is possible. Similarly, entry 602En may identify a subgraph structure 418 that matches a library sine() function or a library cosine() function and includes an annotation 404 indicating that no side effects are possible. Unlike transient data structures used solely within the optimizing compiler during compilation, catalog 212 exists before the compilation using the catalog is started and persists even after compilation is complete. Catalog 212 can also be used by multiple tools 122, rather than functionality hard-coded within a single compiler and thus only available through that single compiler.

[0229] Figure 7 Shown are some examples of syntax subgraph structure identifications 604. Two examples are names 706 of routines 704; one set of routines 708, 704 belonging to library 702, and another set of routines 710, 704 specific to a particular program 204 (sometimes referred to as "user-defined routines").

[0230] The library 702 may be enhanced as taught herein by determining the optimization characteristics 402 of its routines 708 and accordingly creating catalog entries 602. For example, math library routines for certain functions such as sine(), cosine(), absolute value, exponential operation, truncation, minimum, maximum, average, and others may have entries 602 indicating that these functions are pure in the sense that they have no side effects, no local static variables, and no use of I / O streams.

[0231] Figure 7 Some examples of the syntax subgraph structure identification 604 examples illustrated in FIG include a hash value 712. The hash value may be calculated using a secure hash algorithm (SHA), a message digest algorithm such as MD5, or other hash functions. The hash function used may be cryptographically secure in some implementations, but not in every implementation. For example, the hash value used may include a hash 714 of the routine 704, a hash 716 of the subgraph structure 418, a hash 720 of the subgraph structure template 718, or a combination thereof.

[0232] Figure 8Some examples of optimization feature annotation functionality 802 are illustrated, such as a value 804 expression or representation in a data structure that implements the optimization feature annotation 404. Depending on the specifics of the implementation, the value can be a bit flag, an enumeration value, an integer or Boolean flag, a pointer in a list, or other data value. The functionality 802 of a given annotation 404 is an indication of an execution effect 508 or execution value 504 of code 408 that is discernible before the code 408 is executed. Some examples of execution effects 508 include side effects 808, accesses to non-local variables 812, accesses to local static variables 816, accesses to reference parameters 820 (which are special cases of non-local variable 812 accesses), and exceptions 828 (division by zero, overflow, etc.). Use of an I / O device or I / O stream can also be considered an execution effect 508, or it can be considered a negative bound 506 on an execution value (or, if the values available via I / O usage are restricted by known means, a positive bound 506). For example, if it is known at compile time that a variable or expression cannot be zero or negative or must be in the range of -1 and +1, the annotation can indicate that the value is bounded 506. The annotation 404 can indicate 830 that a function or subgraph is non-terminating 832 (e.g., a "condition (true)" loop or function that terminates the program). Identifying a non-terminating code segment via the annotation allows subsequent evaluation to be discarded, such as f() + g(), where f() proves to be non-terminating because it is itself non-terminating (propagation of the annotation 1210), and causes g() to be discarded (since it is never run) and replaced by an unrelated constant, or the entire node to be reduced to "f(); throw".

[0233] In this example, the annotation value 804 may indicate 806 information about side effects, including the presence or absence of the possibility of a side effect 808. The annotation value 804 may also or alternatively indicate 810 information about accesses (reads or writes or both per implementation) to non-local variables 812, including the presence or absence of the possibility of such access. The annotation value 804 may also or alternatively indicate 814 information about accesses to local static variables 816, including the presence or absence of the possibility of such access. The annotation value 804 may also or alternatively indicate 818 information about accesses to reference parameters 820, including the presence or absence of the possibility of such access. The annotation value 804 may also or alternatively indicate 822 information about accesses to I / O devices or I / O streams 824, including the presence or absence of the possibility of such access. The annotation value 804 may also or alternatively indicate 826 information about one or more special exceptions 828, including the presence or absence of the possibility of such exception(s) being raised. The annotation value 804 may also or alternatively indicate 830 information regarding termination or non-termination 832 of the code segment.

[0234] Figure 9Some examples of optimization 900 categories are described. Some optimizations 902, 900 reduce the number of processor 110 cycles executed during execution. Some optimizations 904, 900 reduce the amount of memory 112 (RAM, processor cache, optical disk, memory heap, etc.) used during execution. Some optimizations 906, 900 reduce the use of I / O devices or I / O streams 824 during execution. Some optimizations 908, 900 replace code that performs a series of calculations during execution with code that represents constant values. Some optimizations 912, 900 reduce the use of exception handlers 910 during execution by reducing or eliminating (which is an extreme example of reduction) runtime exceptions 828. Some optimizations 914, 900 replace code that performs a series of calculations during execution with code that sometimes returns previously calculated values 504 instead of recalculating values. Those skilled in the art will also recognize that other optimizations 900 can also be implemented using features 402 and annotations 404 and performed according to the teachings herein.

[0235] Figure 10 An example of a syntax diagram 410 based on code 214, which may also be represented as "f(a, b, c + d * e, g)", is shown, where f is a function name 706, parentheses enclose arguments passed to a call to the function, a plus sign "+" indicates addition, and an asterisk "*" indicates multiplication. For the convenience of the reader, this example syntax diagram includes explicit syntax element identifiers such as "function," "argument," "variable," "expression," and "operator." However, those skilled in the art will recognize that such syntax element identifiers may be implemented, for example, as enumerated values in a data structure, and may be explicit or omitted in other syntax diagram representations. Figure 10 Optimization property annotations 404 are not shown in FIG, but can be added by annotator 406.

[0236] Figure 11 An example of another syntax diagram 410 is shown based on code 214 that can also be expressed as the expression "a(x)*b(x)+c(x) / d(x)", where a, b, c, and d are each function names 706, a set of parentheses encloses the parameter x that happens to be passed to each function call, a plus sign "+" indicates addition, an asterisk "*" indicates multiplication, and a slash sign " / " indicates division. Depending on the meaning of "pure" in comment 404 and the characteristics of the particular functions a, b, c, d, Figure 11 The syntax diagram shows multiple possible optimization cases and different codes 214.

[0237] exist Figure 11404 is shown in FIG. In this example, "pure" is a label that refers to one or more of indications 806, 810, 814, 818, 822, or 826, depending on the implementation. In other examples, purity can have other meanings. In certain cases, functions a and d can be said to be pure in the sense that they have no side effects 808, while functions b and c are only potentially pure in the sense that it has not yet been determined whether they have side effects.

[0238] Some embodiments use or provide a code transformation optimization system 206, 102 that includes a memory 112 and a processor 110 in operable communication with the memory. The processor is configured to perform steps that include (a) traversing at least a portion of a syntax graph 410 of a program 204, (b) identifying a predetermined subgraph structure 418 in the syntax graph, and (c) associating an optimization property annotation 404 with the identified syntax subgraph structure. The resulting association indicates the extent to which aspects 502 of a code segment 408, 214 corresponding to the identified subgraph structure are discernible prior to execution of the code segment. The aspects 502 include execution values 504 or execution effects 508, or both. In this example, the processor is configured to (d) perform optimization 900 of the code transformation 208 of the program based at least in part on the results of the associating step.

[0239] In some embodiments, the memory 112 includes a directory 212 (e.g., contains the directory 212, is configured by the directory 212) having an entry 602. The entry 602 includes an identification 604 of a subgraph structure 418 and also includes an optimization property annotation 404 associated with the identified subgraph structure. A given entry 602 can associate one or more subgraph structures with one or more annotations 404. The directory entry 602 exists before code conversion of the program 204 and also exists after optimization of the code conversion of the program is performed.

[0240] In some embodiments, the identification 604 of the subgraph structure includes or is indexed by at least one of the following keys: the name 706 of a routine 708, 704 of a library 702 utilized by the program 204; the name 706 of a user-defined routine 710, 704 that is part of and specific to the program 204; a hash value 714 of the routine; a hash value 716 of the subgraph structure; or a hash value 720 of a syntax subgraph structure template 718. The template 718 can be viewed as a way to drill one or more holes in the syntax tree to perform a match modulo any of a set of different constants or other trivialities identified by the entry 602 from a syntax perspective.

[0241] In some embodiments, the optimization characteristic annotation 404 includes at least one of: a value indicating 806 whether the code segment corresponding to the identified subgraph structure has no side effects during execution of the code segment; an indication 810 whether the code segment corresponding to the identified subgraph structure accesses the values of any non-local variables during execution of the code segment; an indication 814 whether the code segment corresponding to the identified subgraph structure has the values of any local static variables; an indication 818 whether the code segment corresponding to the identified subgraph structure has the values of any parameters passed by reference to support execution of the code segment; an indication 822 whether the code segment corresponding to the identified subgraph structure accesses any I / O devices or I / O streams during execution of the code segment; a value indicating 830 whether the code segment failed to terminate after execution of the code segment began; or a value indicating 826 whether the code segment corresponding to the identified subgraph structure can throw an exception during execution of the code segment.

[0242] Some embodiments include a pluggable optimizer 424 that the system 206 is configured to invoke to perform the optimization 900. An optimizer is considered "pluggable" when it can be enabled or disabled, or both, without recompiling the code that invokes the optimizer.

[0243] Other system embodiments are also described herein, either directly or as system versions of media derivable from the described processes or configurations, informed by the extensive discussion herein of computing hardware.

[0244] Although specific architectural examples are shown in the figures, embodiments may depart from those examples. For example, items shown in different figures may be included together in an embodiment, items shown in a figure may be omitted, functionality shown in different items may be combined into fewer items or into a single item, items may be renamed, or items may be connected to each other in different ways.

[0245] Examples are provided herein to help illustrate aspects of the technology, but the examples given herein do not describe all possible embodiments. The embodiments are not limited to the specific component names, optimizations, algorithm selections, data, data types, configurations, implementations, arrangements, displays, features, methods, or scenarios provided herein. A given embodiment may include, for example, additional or different technical features, mechanisms, sequences, data structures, or functionality, and may otherwise depart from the examples provided herein.

[0246] Process (i.e., method)

[0247] Figure 12A method 1200 is described, which is an example of a method that can be performed or assisted by the enhanced system 206. The enhanced converter 206 traverses 1202 the syntax graph 410, scanning 1204 the subgraph structures 418 in its way. The converter 206 detects 1206 the presence of optimization features by identifying 1208 the cataloged subgraph structures or by inferring 1210 the optimization features from existing annotations 404 on the graph 410. The converter 206 annotates 1212 the syntax graph accordingly by associating 1214 the annotations with the relevant portions of the graph or corresponding code 408. Next, the optimizer 424 (which is part of the converter 206 or is called by the converter 206 or subsequently operates as a standalone tool 122) performs 1216 optimizations based on the annotated graph and produces 1218 optimized code 210.

[0248] Figure 13 Further illustrated is a code optimization method (also referred to as a process) suitable for use during code conversion, including Figure 12 Unless otherwise indicated, the technical processes shown in the figures or otherwise disclosed will be automatically performed, for example, by the converter 206. The process may also be partially automated or partially manual to the extent that it includes actions by a human administrator or other personnel, for example, in some embodiments, a person can specify which optimization 900 is required. No process is intended to be entirely manual as an innovation herein. In a given embodiment, zero or more of the illustrated steps of the process may be repeated, or different parameters or data may be operated on. The steps in the embodiments may also be performed by the user. Figure 12 and Figure 13 The steps may be performed in a different order from the order listed from top to bottom in the flowchart 1200. The steps may be performed sequentially, in a partially overlapping manner, or completely in parallel. Specifically, the order in which the flowchart 1200 action items or the flowchart 1300 action items are traversed to indicate the steps performed during the process may vary from one embodiment of the process to another. The flowchart traversal order may also vary from one embodiment of the process to another. Steps may also be omitted, combined, renamed, reorganized, performed on one or more machines, or otherwise deviate from the illustrated process, provided that the performed process is operable and complies with at least one claim.

[0249] Some embodiments use or provide a method for finding optimization opportunities during code transformation, the method comprising: scanning 1204 at least a portion of a syntax graph 410 of a program, a syntax graph having nodes 414, a syntax graph representing at least grammatical structural aspects of a program 204; ascertaining 1206 that code 408, 214 of the program associated with a node of the syntax graph has an optimization characteristic 402; and annotating 1212 the syntax graph based on the ascertained optimization characteristic.

[0250] In some embodiments, ascertaining 1206 that the code of the program associated with the node of the syntax graph has the optimization property includes at least one of: matching 1326 the code with an entry 602 in a catalog describing the optimization property; and matching 1326 the syntax subgraph 418 containing the node with an entry 602 in the catalog describing the optimization property. The matching can be accomplished, for example, by calculating and comparing corresponding identifiers of the items; a match is established when the corresponding identifiers are identical.

[0251] In some embodiments, ascertaining 1206 that the code 408 of the program associated with the first node 414 of the syntax graph 410 has the first optimization property 402 includes inferring 1210 from the second optimization property 402 associated with the second node 414 of the syntax graph 410. The first node and the second node have different corresponding positions 1324 in the syntax graph. The first optimization property and the second optimization property can have the same value or different corresponding values. The inference can be used to piece the optimization properties together to construct an optimizable subtree.

[0252] Some embodiments provide 1328 an optimizer 424 accessing the annotated syntax graph. The optimizer then generates 1218 at least one of the following: an optimization 902, 900 to reduce processor cycle counts for executing the program's code; an optimization 904, 900 to reduce memory requirements for executing the program's code; an optimization 906, 900 to reduce I / O requirements for executing the program's code; an optimization 908, 900 to replace code segments of the program with constant values at compile time; an optimization 914, 900 to store data 118 or instructions 116, or both, in the program's code; or an optimization 912, 900 to remove calls or jumps to exception handlers 910 in the program's code.

[0253] In some embodiments, the optimizer 424 generates 1218 optimizations 900 based on the annotated syntax graph, and the optimizations include rewriting 1338 at least a portion of the syntax graph 410. For example, the graph may be rewritten 1338 to implement constant folding or include memoization 914.

[0254] In some embodiments, the optimizer 4242 generates 1330 a plurality of optimization candidates 1370 based on the annotated syntax diagram. The optimizer or converter 206 assigns 1332 respective weights to at least two of the optimization candidates and prioritizes 1336 the optimization candidates based at least in part on their respective assigned weights. For example, when the target system 102 is an IoT device with relatively little memory and little interaction with human users, memory size reduction 904 can be prioritized over speed increase 902.

[0255] Some embodiments insert 1340 a callback 1342 that, when executed, triggers 1346 a partial evaluation 1348 that produces optimizations 900 based at least in part on the annotated syntax diagram. For example, the converter 206 may make multiple passes over a portion of a syntax diagram and may use callbacks to update the annotations 404 for that portion as additional information becomes available from previous passes.

[0256] In some embodiments, ascertaining 1206 does not rely 1350 on the use of programming language keywords 1352 in the source code of program 204 specifically for expressing optimization characteristics. For example, constant folding optimization opportunities can be identified by identifying 1208 that each child node 414 will evaluate to a constant and then inferring 1210 that parent nodes that perform arithmetic operations on those constants will also evaluate to a constant. This is in contrast to the use of C++ constant expression keywords or similar programming language keywords 1352. Unlike the use of programming language keywords, using annotations 404 to implement additional optimizations does not require changes to the programming language specification.

[0257] In some embodiments, ascertaining 1206 includes consulting 1354 a catalog 212 having entries 602 that respectively list optimization characteristics 402 for corresponding code segments 408 or syntax subgraph structures 418 identified 604 in the catalog. Some embodiments update 1356 the catalog to include the additional code segments or additional syntax subgraph structures, and to include corresponding optimization characteristics that match the additional annotations 404 of the syntax graph.

[0258] Configured storage media

[0259] Some embodiments include a configured computer-readable storage medium 112. The storage medium 112 may include a disk (magnetic, optical, or other), RAM, EEPROMS, or other ROM, and / or other configurable memory, including, in particular, a computer-readable storage medium (which is not merely a propagating signal). The configured storage medium may be, in particular, a removable storage medium 114, such as a CD, DVD, or flash memory. General purpose memory, which may or may not be removable and may be volatile or non-volatile, can be configured into an embodiment using items in the form of data 118 and instructions 116 (such as an optimization catalog 212, optimization feature annotations, subgraph structure identification 604, graph annotator 406, and subgraph structure identifier 420), read from the removable storage medium 114 and / or another source (such as a network connection) to form a configured storage medium. The configured storage medium 112 enables the computer system 206 to perform technical process steps for transcoding optimization, as discussed herein. The figures therefore help illustrate configured storage medium embodiments and process (i.e., method) embodiments, as well as system and process embodiments. Specifically, Figure 12 or Figure 13Any of the process steps described in or others taught herein may be used to help configure a storage medium to form a configured storage medium embodiment.

[0260] Some embodiments use or provide a computer-readable storage medium 112, 114 configured with data 118 and instructions 116 that, when executed by a processor 110, performs a method for finding optimization opportunities during code transformation. The method includes: scanning 1204 at least a portion of a syntax graph of a program, a syntax graph having nodes, a syntax graph representing at least grammatical structural aspects of the program; ascertaining 1206 that code of the program associated with a node of the syntax graph has optimization characteristics; annotating 1212 the syntax graph according to the ascertained optimization characteristics; and generating 1218 optimizations for the program based at least in part on the annotated syntax graph.

[0261] In some embodiments, the method further includes forming 1358 or locating 1360 an optimization property subtree 1322, i.e., a set of nodes 414 having the same or inferred associated corresponding optimization properties 402 and also collectively defining a subtree of a syntax graph, consisting of nodes and connections between the nodes in the set.

[0262] In some embodiments, the method further includes annotating 1212 the syntax diagram with possible value annotations 506 that define all possible execution values 504 for a code segment 408, 214 that can assume different values during different program executions and utilizing 1210 the possible value annotations while generating optimizations for the program.

[0263] In some embodiments, the method includes enhancing 1362 the source code of a program by adding a textual representation of a syntax diagram optimization feature annotation 404 to the source code. In some embodiments, the method includes saving 1364 the representation of the syntax diagram optimization feature annotation 404 in a file 1366; the file originating from and specifically associated with the program; the annotation information is saved for use in subsequent code conversions of versions of the program. In some embodiments, the method includes entering 1356 the representation of the syntax diagram optimization feature annotation in a directory 212 not specific to the program for use in subsequent code conversions of the program or in subsequent code conversions of another program, or both.

[0264] In some embodiments, ascertaining 1206 that code 408 of a program associated with a node of syntax graph 410 (represented herein as code F) has optimization characteristics 402 includes ascertaining 1206 that code F is purely functional code in that, for a given set of inputs, executing code F always provides the same execution result when control is transferred from code F to another code. This pure functionality can occur, for example, if code F does not have local static variables or does not use such variables to maintain state between calls. This pure functionality can occur, for example, if code F does not produce results based on randomized variables or results based on I / O streams or device reads.

[0265] Additional Examples and Observations

[0266] Those skilled in the art will recognize that not every part of this disclosure, or any specific detail therein, is necessarily required to satisfy legal standards such as enabling, written description, or best mode. Furthermore, the embodiments are not limited to the specific networks, tools, identifiers, fields, data structures, functions, constants, or other implementation options described herein. Any apparent conflict with any other patent disclosure (even from the owner of the present invention) has no effect on understanding the claims presented in this patent disclosure. With this understanding of all parts of this disclosure, some additional examples and observations are provided.

[0267] More about annotations

[0268] In some embodiments, simple annotations 404 are Boolean values or enumeration flags. For example, for a given function definition of purity, some annotations may be represented as [IsPure(true)] or [IsPure(false)], e.g., purity may be defined as having no side effects 808. Similarly, some annotations may be represented as [ThrowsException(Never)] (never thrown), or [ThrowsException(Fatal)] (unable to handle exceptions, such as corruption), or [ThrowsException(InputValidation)] (only throws exceptions when the input is out of bounds, such as an empty checkbox).

[0269] In some embodiments, some annotations are binary (black / white, on / off, present / absent, etc.), while some other annotations are in a range. Annotations in a range can have a certain ordering, for example, with respect to exception 828, "never raise" is stronger than "raised for verification" which is stronger than "raised for any reason."

[0270] The optimizer 424 can use annotations by combining 1210 the child nodes at the parent node based on their annotations. For example, consider a subtree rooted at the parent node and representing "f(x) + g(x)". If both f and g are pure, then the resulting tree rooted at the node representing + is pure by inference 1210. As another example, consider a subtree rooted at the parent node and representing "f(x) / g(x)". If both f and g never throw an exception, then the resulting subtree rooted at the node representing / may still throw an exception because if g(x) returns 0, then there was an attempt to divide by zero.

[0271] In some embodiments, more complex annotations 404 contain sets or lists. For example, [PossibleExceptions(typeof(DivideByZeroException))] indicates a set or list of exceptions 828 that include DivideByZeroException. Embodiments may use set theoretic algebraic constructs to combine 1210 such annotations 404 in parent nodes. For example, [ThrowsException(Never)] is equivalent to the empty set, and a binary expression node with two child nodes will have the union of the possible exceptions of its child nodes as the set of its possible exceptions. Let the braces represent sets, and consider again the above addition example ("f(x) + g(x)") and the above division example ("f(x) / g(x)"). If f() can throw exception type A and g() can throw exception type A or B, then when the + operation has overflow detection, f(x) + g(x) has the set of possible exception types {A, B} or {A, B, OverflowException}. On the other hand, f(x) / g(x) has the set of possible exception types as {A, B, DivideByZeroException}.

[0272] In some embodiments, the annotations 404 can cross-talk with each other. For example, some functions 704 have domains and ranges. Assume that function f(x) has the domain [0, int.MaxValue] for x, and assume that it has an annotation stating [ThrowsException(InputValidation)]. Assume that the converter or optimizer can establish that the arguments bound to x are within the valid range (e.g., the arguments evaluate to constants within the valid range). Then ArgumentOutOfRangeException does not occur in the set of possible exceptions that may occur for a call to f(x) with the given arguments. Similarly, if g(x) has a bounded range [1, 100], then the use of g(x) in f(x) / g(x) precludes the occurrence of DivideByZeroException.

[0273] In some embodiments, some annotators 406 or annotations 404 use path traversal to create lazily evaluated annotation values. Consider this code snippet: a(x)*b(x)+c(x) / d(x). The syntax tree 410 for this code is represented in Figure 11 For the sake of clarity, Figure 11 Only some of the possible annotations for the tree are explicitly shown.

[0274] The annotation 404 for the + node 414 may be similar to [IsPure(IsPure(Left.Right)&IsPure(Right.Left))], which means that the purity of the node is the & of the purity values determined for b(x) (with respect to the Left.Right of +) and c(x) (with respect to the Right.Left of +), where & represents a logical AND. This may be the case because the tool may determine that a(x) and d(x) are unconditionally pure, and b(x) and c(x) are definitely pure (in which case the entire expression would be impure), but the next stage of the optimizer's work requires a closer look at b(x) and c(x) to determine what additional optimization properties can be determined. It may be true that a(x) and d(x) are in the catalog 212. Alternatively, a(x) and d(x) may be insignificant with respect to the optimization properties, for example, they may be missing division, local variables, and I / O calls, while b(x) and c(x) are not in the catalog and are not insignificant.

[0275] In many cases, a purity property is a logical AND of the purity of the dependent products (e.g., child nodes). For example, IsPure(x+y) = IsPure(x) AND IsPure(y) when purity is defined in terms of side effects, accessing non-local variables, using static local variables, using reference parameters, or using I / O streams or devices.

[0276] More generally, in some embodiments, a path expression describes a traversal in the graph 410 starting from the current node. Left / Right is only a way to navigate from a binary node. A more general form is an encoding of the path using the index of the edge 416. For example, f(a,b,c,d) can use a path represented as Arguments[2] to navigate to the node representing c, where Arguments[1] indicates b and Arguments[0] indicates a. As another example, a traversal path represented as [3,1,0] in the graph representing f(a,b,c+d*e,g) can refer to d; in this example, node 3 of the function is c+d*e (0:f, 1:a, 2:b, etc.), child node 1 of node c+d*e is d*e, and child node 0 of node d*e is d.

[0277] In some embodiments, the inference 1210 or traversal path can be even more complex to represent branching during optimization attempts. For example, consider code expressed as f(x)? g(x) : h(x), using familiar C syntax; this can also be expressed as "if f(x) then g(x) else h(x)." If f is a pure function but x is unknown, then the tools 206, 424 cannot evaluate f(x) at compile time. The tools can also find that g(x) is pure, but h(x) is not. It is not until runtime that f(x) will have a definite value of true or false, and the purity of the entire expression can be known. However, it may be that this entire expression occurs within a larger expression, and when the larger expression is inlined, the tools can evaluate f(x) and end up with g(x) or h(x) and determine the purity. Therefore, the annotation 404 can use other Boolean algebra, such as => implications, to formulate the logical proposition that expresses the conditional purity as an optimization characteristic 402.

[0278] More on callbacks and partial evaluation

[0279] In some embodiments, the callback implements an agreement between (a) the syntax diagram viewer 412 and analyzer 420 and (b) the optimization provider 424. The first converter 206 view of the syntax diagram 410 can be relatively general. For example, the converter can view the syntax tree in a depth-first manner, determine the semantic information of the nodes 414 (e.g., nodes where the constant value 422 is a constant, never raises an exception, etc.), and then combine 1358, 1210 when it restores the tree, again using a semantic provider that knows how to combine annotations. As used herein, "semantics provider" refers to the optimization annotation semantic functionality described herein, which can be implemented in the graph annotator 406, the subgraph structure identifier 420, the optimizer 424, the catalog 212, or any combination thereof.

[0280] For example, consider a subtree representing a code that can be expressed as "1 + 2". In this case, the nodes representing 1 and 2 are pure, so + can combine the two cases of being pure in the root entity that is pure for the 1 + 2 subtree (or, in some implementations, equivalently, for the + node at the root of the subtree).

[0281] The callback 1342 is used when the optimizer 424 is implemented to effectively instruct other transformation software that if the other software encounters a node that is pure (but its parent is not), then the node and state should be provided to the optimizer so that the optimizer can perform optimizations on it.

[0282] For example, consider "f(1+2)". If f is not pure, the optimizer sets instructions in place to provide the optimizer access to the f(1+2) node at a later time, with a callback conveying the information that the node's child 1 (which, in the call to f with that argument, represents the child of 1+2) is pure. The optimizer can then perform 1346 a partial evaluation 1348 of 1+2 and tell the rewriter 426 that the value has become 3, so the rewriter can change 1338 the tree to f(3).

[0283] As another example, consider the following exception handling code:

[0284]

[0285] If the analyzer 206 or 424 concludes that f(x) can throw Bar but cannot throw Foo, and the optimizer 424 has requested a callback when looking for nodes with deterministic exception behavior, then this callback 1342 can be made 1340 to effectively say "child node 0 of this try statement can throw {BarException, QuxException}." The optimizer 424 can then request removal of the handler 910 for FooException because the FooException may never have occurred.

[0286] Notice also that this analyzer is able to create an annotation 404 for the entire try statement to have a set of possible exceptions 828 corresponding to PossibleExceptions("f(x)")\{BarException}U PossibleExceptions(" / / bar it"). This is another example of using set theory to combine 1358 annotation values in this case. In this description, "U" represents the set theory union operator, and "\" represents the difference set. In the context of another try...catch...statement shown below, the set of possible exceptions that may be thrown from the try statement is PossibleExceptions(try_body)\{E1,E2}UPossibleExceptions(catch_body1)U PossibleExceptions(catch_body2). Here is the corresponding try...catch...statement:

[0287]

[0288] The catch clause takes away E1 and E2 (hence the use of \ as the difference), but the bodies of these catch blocks can throw more exceptions that need to be unioned within them.

[0289] In some embodiments, the optimizer 424 can be injected to run at runtime rather than just at compile time. For example, consider the code "GetBigSet().Contains(x)", which checks whether item x is a member of a large set of items. The precise meaning of "large" can depend on the particular system 102 involved, but some of the available measures can be, for example, that the set is too large to fit entirely in available RAM, or that the set is so large that iterating through half of its members would take so long on the available computing power that a human user would consider the program unresponsive.

[0290] Here, the analyzer 206 or 424 can infer that GetBigSet() is pure, so it can be represented as a constant containing a big set (as the name implies). But it may be unknown whether this code "GetBigSet().Contains(x)" will run, so the memory 112 allocated to hold the constant will be wasted. A special case occurs when x is a constant, allowing the optimizer 424 (at least in memory) to evaluate the code as true or false at compile time. Assume that x is not a constant. Then either the tool leaves the code as is, which can generate a lot of CPU time when the code is run multiple times, or the tool reduces the GetBigSet() call to a big set constant.

[0291] An alternative for the optimizer in this example is to attempt a reduction to a large set constant, infer (based on, for example, administrative settings or configuration files or heuristics) that the result will use more memory than necessary, and defer applying the optimization until runtime by rewriting the tree to "Memoize(() => GetBigSet()).Contains(x)", where Memoize provides a function for the optimizer to perform memoization. This memoization function can internally hide cache behavior, frequency analysis, etc. to implement a strategy to free up memory for the large set when it is not frequently used based on runtime dynamic behavior. In effect, this inserts 1340 a callback to the optimizer to run the optimizer while the program 204 is running.

[0292] In the code representation "Memoize(()=>GetBigSet()).Contains(x)", "()" and "=>" indicate the presence of a lambda expression. This particular annotation is from the lambda expression syntax of C#. In it, () is an empty parameter list, and => is the marker indicating a lambda. Therefore, it provides a way to write a callback that does not take any arguments. Similar annotations in some other programming languages are:

[0293] C#: ()=>foo-or-delegate(){return foo;}

[0294] VB: Function()foo

[0295] JavaScript: function(){return foo;}

[0296] C++[](){returnfoo;}

[0297] The ability of the optimizer 424 to inject itself to run at runtime rather than just at compile time provides technical benefits. In the above example, a traditional optimizer must decide whether to move the evaluation of GetBigSet() to a common location or leave it in its original location. The enhanced optimizer taught in this article is not forced to choose between these two extremes. In addition, in an environment with long-running code, updates to the catalog 212 used by the optimizer can affect the running code long after the compile-time optimization traversal has been performed. For example, an entire code segment can be considered to be infrequently run (perhaps due to previous calls to this code, which have already supplied statistics to the catalog), so the optimizer can decide to run itself at the target code by lifting the code into a lambda. It will not have to be a Memoize(() => code) operation, but can instead be similar to an Eval(() => code) operation, because the code purity has not yet been necessarily assessed. The optimizer can install itself via a callback to run at a later time, which can also be when the catalog contains more information or additional updated information. Memoization can be viewed as a special case of calling the optimizer at runtime with CPU / memory trade-offs using compile-time optimizer knowledge of code purity. The more general case is calling the optimizer at runtime, possibly with hints from knowledge inferred at compile time.

[0298] More about optimization prioritization

[0299] As discussed elsewhere herein, optimization candidates 1370 can be prioritized 1336 based on their relative weights 1334. The prioritization weight function can measure various items such as CPU cycles used, memory allocations made (and, in some implementations, the number of garbage collections triggered), and the total size of the resulting constants in memory based on the evaluation of pure (sub)expressions at compile time. These values can be placed in annotations 404 so that they can be utilized by subsequent optimizer passes.

[0300] In some embodiments, other weights are based on the static shape of code 408 or properties of code 408. For example, the number of child nodes 414 can be a reflection of code complexity, such as the presence of loops in the code (which can be CPU intensive), or the presence of a call to a "new" operator in C++ code or another expression that constructs or allocates memory.

[0301] This highlights the flexibility of the teachings presented herein. While various programming languages may have annotations for purity or immutability (e.g., C++'s "constexpr") or exceptional behavior (e.g., Java's "throws"), they lack other characteristic indications, such as annotation 404 indicating that code 408 "assigns," "may assign," or "never assigns."

[0302] The specific definition and use of optimization candidate weights 1334 may vary between implementations. One may involve thresholds set by the user; for example, an embodiment may evaluate 1348 whether doing so will not use more than x bytes of memory 112, or evaluate 1348 whether the evaluation will take less than x seconds at compile time regardless of memory usage. In some cases, a policy engine is inserted. In some cases, machine learning is used, for example, the optimizer 424 may place 1340 learning callbacks 1342 in omitted code to reinforce or guide optimization decisions and better align future decisions with observed behavior.

[0303] More about annotation combinations

[0304] Embodiments may use the viewer 412 above the diagram or the tree representation 410 of the code 214 to query the semantics provider and obtain a wide variety of annotations 404. An algebra of these annotations may be provided by the semantics provider, and ways of combining 1358, 1210 annotations may be provided (e.g., logical AND represented herein as "&", unions, etc.). Callbacks 1342 registered by the optimizer may be used to make optimization decisions, such as, "if this allocates, then evaluate it at compile time, or add 1212 another annotation to the node allocation to communicate that it may throw an OutOfMemoryException". By evaluating a code segment at compile time to a constant value, subsequent optimizations may become possible, which results in fewer allocations being required at runtime. A general case illustrating this benefit is: "newman("Bart", 21).age", which after optimization skips the allocation of the string and person at runtime and only obtains the age attribute which is the constant 21.

[0305] With respect to the algebra of annotations provided by the semantic provider 212, 406, 420, or 424, including the manner in which the annotations 1358, 1210 are combined, in some embodiments, the semantic provider acts as an aggregation function in the sense that when the semantic provider is provided with annotations 404 for N child nodes 414 and a reference to a parent node 414, then it returns a set of annotations for the parent node.

[0306] For example, consider a code subtree represented by "x / f(y)", where " / " represents division. In this example, the syntax viewer 206 (including the syntax traverser 412) first analyzes "x" and asks the semantic provider (including the subgraph structure identifier 420 and the annotator 406) for annotations, providing the semantic provider with a reference to the node representing "x" and an empty set of annotations (empty because "x" has no child nodes). The semantic provider can return a set of annotations, such as {IsPure(true)}.

[0307] Next, the syntax viewer analyzes "y" and asks the semantic provider for annotations 404, providing it with a reference to "y" and an empty set of annotations since "y" has no child nodes. The semantic provider may return a set of annotations such as {IsPure(true)}.

[0308] Next, the syntax viewer analyzes "f(y)" and asks the semantics provider for annotations, providing it with a reference to "f(y)" and a set of annotations for "y" {IsPure(true)}. The semantics provider can return a set of annotations such as {IsPure(true)}, PossibleExceptions(Foo), Range(1,100)}. In this example, the annotation Range(1,100) is bound 506, which indicates that the range (as opposed to domain; as in "range" in "function range") of the function f is limited to values from 1 to 100.

[0309] Next, the syntax viewer parses "x / f(y)", asks the semantics provider for an annotation, providing it with a reference to "x / f(y)" and the set {IsPure(true)} for the left side and {IsPure(true), PossibleExceptions(Foo), Range(1,100)} for the right side. The semantics provider can return a set of annotations, such as {IsPure(true)}, PossibleExceptions(Foo)}. In this step, note that the semantics provider uses the annotation Range(1,100) obtained for the right operand of the / division and uses it to not add the DivideByZeroException to the set of possible exceptions 828 for the node representing the division. In contrast, if the range already included zero, or if no range was returned for the child node and therefore zero was not excluded, then the DivideByZeroException would be incorporated into the set of possible exceptions.

[0310] More about the catalog

[0311] A relatively simple directory 212 is a directory for opaque library functions 708, and the optimizer cannot detect this function by viewing this function. For example, routine Math.Sin is known to be pure and never causes, but is implemented as a CPU instruction that the optimizer does not need to understand. Pure function can also be implemented as a complex algorithm written in another language such as C or Fortran that the optimizer does not have parsing, or the source code for the routine can not be used to analyze the routine for purity. In certain embodiments, directory 212 maps name "Math.Sin" 706,604 or its hash 712,604 to its purity annotation 404, thereby effectively providing optimization knowledge for the leaf node in the syntax diagram 410. In this example, this directory is static and provided by developers prior to compile time.

[0312] Some embodiments use or provide a higher-level directory 212 that identifies user-defined functions 710. The optimization feature 402 analysis of the function code occurs once, and the results 602 are stored. The key 604 in the directory can again be the function name 706, but the directory entry 602 can also contain more information, such as a version number, or the module in which the function 710 is defined, or even a hash 714 of the code in the function. The hash 714 can be used to help ensure that changes to the function's code 408 invalidate the association 1214 of the annotation to the code, because the association may no longer be valid after the code is changed. Additions 1356 to this directory can be explicitly triggered, for example, in a "define function" operation, or the directory update 1356 can be delayed until the first use of the function in a larger code segment is encountered, or the update 1356 can be performed in an offline process, for example, via a nightly job or background process.

[0313] In some embodiments, even higher-level directories 212 have keys 604 that do not refer to named (non-anonymous as opposed to anonymous) functions but rather represent some hash 716 or 720 of a syntax (sub)tree. For example, suppose the parsed code snippet 214 contains a subexpression of the form "a+b*c-d", where a, b, c, and d are themselves trees. An embodiment can create 1356 directory entries 602 that store annotations 404 for the entire code snippet and are indexed 604 by the hash 712 of "a+b*c-d".

[0314] Implementation details can vary. For example, one skilled in the art can select the size of entry 602 to balance storage requirements with expected (or measured) frequency of use. When an entry is too specific and therefore infrequently used, and is still relatively large, it can be a waste of storage. Even relatively small entries 602 can be wasteful if they are too specific, such as an entry stating 3.1415 as a constant, or 2*PI as a constant, or Math.Sin(30) / 2 as a constant.

[0315] It is also possible to often reuse large trees but always change only slightly in some part. For example, a tax calculation can be a complex formula that is usually networked as a larger expression (as opposed to a named auxiliary function), and is always the same modulo a constant (e.g., a tax rate bracket or a percentage). To accommodate such a situation, one can increase the constant and the pure nodes in the expression and figure out the results. For example, "f(x)*0.2-g(x)" and "f(x)*0.3-g(x)" can become "f(x)*cg(x)" for different values of the constant c. Therefore, c is a type of hole in the expression, and "f(x)*cg(x)" can be represented as a subgraph structure template 718 accordingly. The hash 720 of this rewritten expression can be used as a key 604 in the directory 2121 to track the semantic information of "f(x)*cg(x)" for any value of c.

[0316] In some cases, if the tree becomes generalized using this technique of creating templates, more unknowns are introduced. For example: f(x) / 2 can become f(x) / c for any value of c. However, if c becomes 0, the properties of the resulting code are different from the case where c is not 0. This is a recollection of the "conditional annotations" discussed earlier in this disclosure. This is an example where the set of exceptions depends on the value of c. In the case of the example with conditional purity discussed earlier, this annotation could be something like [ThrowsExceptionIf(typeof(DivideByZeroException), c==0)], whereby the condition becomes encoded in the annotation. As an additional observation, in some cases, such conditional annotations can tend to cascade. Suppose there is an exceptional condition on the input, and the entire expression is part of a larger try...catch...statement. Then the stated exceptions also become conditional (and typically have more complex predicates describing these conditions). This can lead to truncation points, where the generalization of code using the template code technique is restricted so that the complexity of these conditions in the annotation is not unbounded.

[0317] As a side note, if the template represents "f(x) / cg(x)", then comment 404 may have conditions regarding the possibility of a divide-by-zero exception due to the division depending on the value of c.

[0318] The grammar viewer can compute a template hash 720 as it traverses 1202 the tree 410 in a bottom-up fashion, drilling holes in the tree representation to perform matches modulo a constant (or other trivialities), and thereby improve the likelihood of a match 1326. More complex data structures can be used to optimize this hash calculation and improve the efficiency of searching for entries 602 in the directory. For example, the directory entry for "f(x)" can remember that there is a related entry for "f(x)*c", so the grammar viewer knows that if the parent node "f(x)" is a multiplication, then it should check the directory again for a match for the parent node. In this case, the directory is effectively an optimized inverted index.

[0319] In short, the directory 212 can be static (a one-time definition of all entries 602) or dynamic (additional or modified entries as more code 214 is analyzed). Furthermore, a match 1326 to an entry 602 can be exact (e.g., by matching a name or a full hash), or a match 1326 can be fuzzy (e.g., a match on a partial hash). Thus, the scope of directory embodiments and their use is quite large.

[0320] More on origins and context

[0321] Some of the early views of the teachings herein relate to constant merging with effect annotations. By virtue of context, some compilers include an optimization step for performing constant merging to reduce the execution time of the generated code by evaluating parts of the program at compile time. These optimizations are generally based on the built-in knowledge of primitive types and the knowledge of their operational safety optimizations. Library functions are generally unknown to the compiler and therefore do not undergo such optimizations. Some of the teachings provided herein describe a rich semantic provider mechanism that provides information to the compiler to perform more thorough optimizations. As a side note, those skilled in the art will recognize that a statement that software "knows" (or does not know) the effect of some data or some capabilities means that the software is properly equipped or designed or configured (or not equipped or designed or configured) to process the data or perform the calculation that provides the capability. Similarly, saying that software "understands" (or does not understand) an item means that the software is properly equipped or designed or configured (or not equipped or designed or configured) to process the item by computational means.

[0322] Some compilers have a rich set of primitive types that they have a deep semantic understanding of and thus provide optimizations for. An example is the C# compiler, which understands the "+" concatenation operator on strings and safely performs optimizations. The C# semantics of "+" align with the runtime behavior of the "Concat" function, and the language and runtime are kept in sync.

[0323] As another example, consider regular expressions. Through the beneficial application of the teachings provided herein, many such small languages can be supported by marking library functions with only semantic information. For example: "String.Format("{0}is{1)", person.Name, person.Age);" can be pure, without the compiler having to understand the format string passed to Format. In this particular example, Format does not have to be pure because it has hidden parameters about the culture of the user's machine for printing, for example, decimals with the desired decimal separator or dates in the desired format. However, the rest of Format is pure because it uses a fixed culture. Assuming that annotations can be provided in a separate method, some embodiments do not suffer from extreme special cases in the compiler code to train the compiler about changes in library functions. Another example is "newRegex("[0-9]*").Match(42)". The directory can contain information about Regex and Match being pure functions, and then optimizations proceed automatically.

[0324] Some compilers have deep built-in knowledge of the individual libraries 702 or frameworks of libraries 702 that they target during compilation, and include optimizations tailored to those libraries. For example, some C++ compilers understand "printf" and the mini-language embedded in printf arguments (e.g., the %d placeholder), allowing those compilers to perform some optimized calculations of format strings at compile time. This is where the semantics of the runtime library leak into the compiler.

[0325] Some compilers rely on language extensions to perform or guide more aggressive optimizations. Examples include compile-time extensions for code and the introduction of macro languages with C++'s "constexpr". This approach does not allow existing libraries to be annotated with semantic knowledge (without source-level editing), and also lacks other types of annotations 404 that can be used by the optimizer 424, such as guarantees about exceptional behavior. In order to introduce these in a manner similar to C++ "constexpr", the language would need a plethora of additional keywords 1352. In contrast, some of the teachings presented herein provide extensible semantic annotations 404 that can guide optimizations without relying 1350 on new keywords.

[0326] In some embodiments, an abstract syntax tree 410 describing a program is scanned bottom-up to discover information about code entities 408 referenced by various nodes 414. As an example, consider a node that executes a method call. When this node is encountered, a semantics provider is consulted to answer questions such as whether the method is a pure function (e.g., a person like Math.Sin), whether the method throws an exception (e.g., a division operator for BigInteger), etc. This semantic information 402 is stitched 1358 together to find the largest spanning subtree that shares certain optimization properties 402.

[0327] For example, Math.Sin and Math.Cos are assumed to be pure in each of the ways represented herein using reference numerals 806 (no side effects), 810 (no external variable access), 814 (no static locals), 822 (no I / O), and 826 (cannot raise exceptions). Under this assumption, applying these functions to stable values (e.g., variables passed by value) will also be pure in those senses and as indicated by reference numeral 818 (no reference parameters). Additionally, Math.Pow can be found to be pure in the same sense, so an expression such as "Math.Pow(Math.Sin(x), 2) + Math.Pow(Math.Cos(x), 2)" can be considered completely pure. Using the trigonometric identity (sine squared plus cosine squared equals one) then allows the optimizer 424 to reduce the entire expression to a constant value of one.

[0328] As a side note, those skilled in the art will recognize that, except for this application of mathematical trigonometric identities, numbers and calculations are not the same. In mathematics, there is no concept of an overflow exception. However, in this discussion of calculations, the argument regarding the size of the function result and the assumption regarding the size of integer or floating point storage and how value 504 is represented in that storage 112 form the basis for the assumption that an overflow exception will not be raised.

[0329] Building on this Math.Sin and Math.Cos example, one mechanism of the scheme 206, 1200 taught herein involves (a) discovering 1206, 1210 the semantic attributes 402 associated with a node, given the semantic attributes discovered 1206, 1208, 1210 for its child nodes, and (b) calling 1216 an optimization provider 424 when certain assertions about these semantic attributes are evaluated to be true. In purity analysis, the corresponding optimization provider can be a provider that requests a callback 1342 when a node is deemed pure, thereby enabling it to trigger a partial evaluation 1348, thereby reducing the node to a constant. After all semantic attributes have been evaluated, these optimization providers 424 can be called during either a first (bottom-up) traversal or a second (top-down) traversal through the syntax tree 410, allowing for the discovery 1358 of the largest portion of the tree 410 where certain attributes 402 hold.

[0330] In addition, some optimization providers 424 can return new rewrites 1338 of the tree 410 to the optimization analysis driver 420 or 406, which can apply 1336 weight functions 1334 to (locally) decide which optimization provider 424 provides the greatest or most needed gains. In some embodiments, these cost functions 1334 are pluggable and can leverage all semantic information discovered when scanning 1204 the tree (or, in the case of the most recently rewritten 1338 tree, post-optimization). For example, one cost provider 1334 can consider the number of constants (more, better, because fewer evaluations), while another cost provider 1334 can assess the cost by evaluating the original tree and comparing the cost to evaluating the new tree, while still another can perform algebraic operations based on criteria such as the estimated cost reported for a node (e.g., number of CPU cycles, memory cost, I / O activity, etc.).

[0331] In some embodiments, discovering semantic information 402, 404 occurs via a provider that can be returned via the catalog 212. In one implementation, the catalog used internally is for Microsoft .NET TM The information in catalog 212 can be supplied in part from existing metadata annotations (eg, host protection attributes, purity annotations) or can be provided manually.

[0332] As discussed herein, some embodiments provide or use an extensible annotation mechanism to indicate optimization opportunities on code entities 408, such as functions, members, types, and the like. Annotations 404 that indicate behavior related to side effects, function purity, and the like are associated 1214 with the code entities to help optimizers 424 determine whether candidate optimizations can be performed safely. Some optimizers 424 adhere to the insertion architecture, and some can be discovered via annotations and then participate in the optimization phase of the compiler pipeline.

[0333] In some embodiments, the annotation capabilities taught herein are layered on top of existing languages and runtimes, rather than changing the languages or runtimes. This distinguishes these embodiments from approaches like adding constant expressions to C++ or approaches by which programming languages themselves gain a notion of pure functions versus functions with side effects (e.g., Haskell with IO monads). Many of the tools and techniques taught herein can be applied to existing languages and runtimes, for example, to optimize the backend of a service. Thus, a cloud service that evaluates many expressions can be provided by applying optimizations even if the underlying language (e.g., C#) or runtime (e.g., Microsoft Common Language Runtime) or library (e.g., Microsoft .NET library) does not provide deep semantic information that can be exploited to perform such optimizations.

[0334] Some additional combinations and variations

[0335] Any of these combinations of code, data structures, logic, components, communications, and / or functional equivalents thereof may also be combined with any of the above-described systems and variations thereof. The process may include any of the steps described herein in any subset or combination or order that may be operated. Each variant may occur alone or in combination with any one or more of the other variants. Each variant may occur using any of the processes in the process, and each process may be combined with any one or more of the other processes. Each process or combination of processes comprising a variant may be combined with any of the configured storage medium combinations and variants described above.

[0336] in conclusion

[0337] In short, the teachings provided herein can be applied to locate and record optimization opportunities, thereby enhancing code transformation 1302 by a compiler 122 or interpreter 122. In some embodiments, an enhanced translator 122, 206 scans 1204 a program 204 syntax graph 410, identifies 1208 a subgraph structure 418, and annotates 1212 nodes 414 of the graph 410 to record optimization characteristics 402 of program code entries 408 associated 1214 with the nodes 414. The subgraph structure 418 and corresponding annotations 404 can be maintained 1356 in an optimization catalog 212 that is distinct from any particular optimizable program 204. An optimizer 424 improves program code 214 transformation 208 based on the annotated syntax graph 410.

[0338] In some embodiments, the optimization characteristics 402 may specify 1308 code purity with respect to possible execution values 504 (including value ranges 506) and potential execution behaviors 508, e.g., side effects 808, use of local static variables 816 or use of global variables 812, use of I / O 824, use of reference parameters 820, exceptions 828 being possible during program execution and non-termination 832 of code.

[0339] In some embodiments, the subgraph structure 418 may be identified 604 using the routine 704 name 706 , the hash value 712 , and a template 718 with holes to be filled by any constants.

[0340] In some embodiments, the optimized characteristic 402 of the parent node 414 may be inferred 1210 from the characteristic 402 of the child node 414 .

[0341] In some embodiments, optimization candidates 1370 may be prioritized 1336 using weight function 1334 .

[0342] In some embodiments, optimizer 424 callbacks 1342 may be inserted 1340 into graph 410 or code 408 to incrementally evaluate 1348 optimization properties 402 .

[0343] Embodiments are understood to also include or benefit from testing and appropriate security and privacy controls, such as the General Data Protection Regulation (GDPR), e.g., it should be understood that appropriate measures should be taken to help prevent misuse of code conversion (such as, injection of malware during conversion) and to help avoid tampering with any personal or private information that the conversion may process during program execution. The use of the tools and techniques taught herein is compatible with the use of such controls.

[0344] Although specific embodiments are explicitly illustrated and described herein as processes, configured storage media, or systems, it will be appreciated that discussion of one type of embodiment generally extends to other types of embodiments as well. Figure 12 and Figure 13The description of the process also helps describe the configured storage medium and helps describe the technical effects and operation of the system and manufacturing as discussed in conjunction with other figures. It is not necessary to necessarily read into each other to follow the limitations of one embodiment. In particular, when discussing systems or manufacturing such as configured memory, the process is not necessarily limited to the data structures and arrangements presented.

[0345] Those skilled in the art will appreciate that implementation details may relate to specific code, such as specific APIs, specific fields, specific types of components, and specific sample programs, and therefore need not appear in every embodiment. Those skilled in the art will also appreciate that program identifiers and some other terms used to discuss details are implementation-specific and therefore need not relate to every embodiment. However, although not necessarily presented herein, such details may be provided to help some readers and / or illustrate several of the many possible implementations of the technology discussed herein by providing text.

[0346] Reference herein to an embodiment having a certain feature X and reference elsewhere herein to an embodiment having a certain feature Y does not exclude embodiments of the disclosure having both feature X and feature Y, unless such exclusion is expressly stated herein. All possible negative claim limits are within the scope of the disclosure, in the sense that any feature stated as part of an embodiment may also be expressly excluded from inclusion in another embodiment, even if no specific exclusion is given in any example herein. The term "embodiment" is used herein merely as a more convenient form of "process, system, article, configured computer-readable storage medium, and / or other example of the teachings herein as applied in a manner consistent with applicable law." Thus, a given "embodiment" may include any combination of the features disclosed herein, provided that the embodiment is consistent with at least one claim.

[0347] Not every item shown in the figures need to be presented in each embodiment. On the contrary, an embodiment may include (multiple) items not explicitly shown in the figures. Although some possibilities are described here in the text and figures by specific examples, an embodiment may be separated from these examples. For example, the specific technical effects or technical features of the examples may be omitted, re-ordered, grouped in different ways, repeated, instantiated in hardware and / or software in different ways, or be a mixture of the effects or features that appear in two or more examples in the examples. In some embodiments, the functionality shown in one position may also be provided at different positions; Those skilled in the art recognize that functional modules can be defined in various ways in a given implementation without having to omit the required technical effects from a set of interactive modules considered as a whole. Due to space limitations or for convenience, different steps can be shown together in a single frame in the figure, but are separately executable, such as one can be executed without executing another in a given performance of the method.

[0348] Reference will now be made throughout the text to the figures by reference numerals. Any apparent inconsistency in the phrases associated with a given reference numeral in the figures or text should be understood to simply broaden the scope of the reference by that numeral. Different instances of a given reference numeral may refer to different embodiments, even when the same reference numeral is used. Similarly, a given reference numeral may be used to refer to a verb, noun, and / or corresponding instance of each, e.g., processor 110 may process 110 instructions by executing the instructions.

[0349] As used herein, terms such as "a," "an," and "the" include one or more of the indicated items or steps. Specifically, in the claims, reference to an item generally means that at least one of the item is present, and reference to a step means at least one instance of performing the step. Similarly, when the context permits, "is" and other singular verb forms should be understood to include the possibility of "are" and other plural forms to avoid grammatical errors or misunderstandings.

[0350] Headings are for convenience only; information on a given topic may be found outside the section whose title indicates that topic.

[0351] All claims and the abstract of the application are incorporated into this specification.

[0352] To the extent that any term used herein indicates or otherwise refers to an industry standard and to the extent applicable law requires identification of a particular version of such a standard, this disclosure should be understood to refer to the most recent version of that standard that has been published in at least draft form (with final form taking precedence if newer) as of the earliest priority date of this disclosure under applicable patent law.

[0353] Although exemplary embodiments have been shown in the figures and described above, it will be apparent to those skilled in the art that many modifications can be made without departing from the principles and concepts set forth in the claims, and that such modifications do not need to encompass all abstract concepts. Although the subject matter is described in language specific to structural features and / or procedural actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific technical features or actions described in the claims. It is not necessary to present or utilize every manner, aspect, or technical effect identified in a given definition or example in each embodiment. In fact, the specific features, actions, and effects described are disclosed as examples for consideration when implementing the claims.

[0354] All changes that do not encompass the entire abstract concept but come within the meaning and range of equivalency of the claims are embraced within their scope to the full extent permitted by law.

Claims

1. A code conversion optimization system comprising: Memory; a processor in operable communication with the memory, the processor configured to execute steps comprising (a) traversing at least a portion of a syntax graph of a program, (b) identifying a predetermined subgraph structure in the syntax graph, (c) annotating the identified syntax subgraph structure with an optimization property annotation, the optimization property annotation indicating the presence or absence of functional purity of a code segment corresponding to the identified subgraph structure, and (d) performing an optimization of a code transformation of the program based at least in part on a result of the annotation step; as well as The memory includes a directory having entries, the entries including an identification of the subgraph structure and the optimization property annotation associated with the identified subgraph structure, the entries existing before the code conversion of the program and also existing after the optimization of the code conversion of the program is performed.

2. The system of claim 1 , wherein the identification of the subgraph structure comprises or is indexed by at least one of the following keys: the names of routines in the libraries utilized by the program; the name of a user-defined routine that is part of and specific to the program; The hash value of the routine; A hash value of the subgraph structure; or A hash of the syntax subgraph structure template.

3. The system of claim 1 , wherein the optimization property annotation indicates at least one of the following: whether the code segment corresponding to the identified subgraph structure accesses any non-local variables during execution of the code segment; whether the code segment corresponding to the identified subgraph structure has any local static variables; whether the code segment corresponding to the identified subgraph structure has any parameters passed by reference to support execution of the code segment; whether the code segment corresponding to the identified subgraph structure accesses any I / O device or I / O stream during execution of the code segment; whether the code segment fails to terminate after execution of the code segment has begun; or Whether the code segment corresponding to the identified subgraph structure can throw an exception during execution of the code segment.

4. The system of claim 1 , comprising a pluggable optimizer, the system being configured to invoke the pluggable optimizer to perform the optimization, wherein the optimizer is considered pluggable when the optimizer can be enabled or disabled, or both, without recompiling code that invokes the optimizer. 5 . The system of claim 1 , wherein the optimization property annotation indicates whether the code segment corresponding to the identified subgraph structure has no side effects during execution of the code segment.

6. A method for finding optimization opportunities during transcoding, the method comprising: scanning at least a portion of a syntax graph of a program, the syntax graph having nodes, the syntax graph representing at least aspects of a grammatical structure of the program; Ascertaining that a code segment of the program associated with a node of the syntax graph has an optimization characteristic; annotating the syntax diagram with an optimization property annotation based on the ascertained optimization property, the optimization property annotation including an execution value of the code segment discernible prior to execution of the code segment, or specifying a degree of functional purity of the code segment, or both; and A catalog is consulted that associates the optimization property annotations with identifications of corresponding portions of the syntax graph of the program, the catalog being distinct from the program and existing before scanning the program syntax graph and after the code transformation of the program is performed.

7. The method according to claim 6, wherein ascertaining that the code segment of the program associated with the node of the syntax graph has the optimization characteristic comprises at least one of the following: matching the code segments with entries in the catalog describing the optimization characteristics; A syntax subgraph containing the node is matched to an entry in the directory describing the optimization property.

8. The method of claim 6, wherein ascertaining that the code segment of the program associated with the first node of the syntax graph has a first optimization characteristic comprises: An inference is made based on a second optimization characteristic associated with a second node of the syntax graph, the first node and the second node having different respective positions in the syntax graph, the first optimization characteristic and the second optimization characteristic having the same or different respective values.

9. The method of claim 6 , further comprising providing access to the annotated syntax diagram to an optimizer, and the optimizer producing at least one of: optimization that reduces processor cycle count for execution of said code segment of said program; optimizations that reduce memory requirements for execution of said code segments of said program; optimizations that reduce I / O requirements for execution of the code segment of the program; An optimization that replaces a portion of the program with a constant value at compile time; Optimization of storing data or instructions or both in said code segment of said program; or Optimization of calling or jumping to an exception handler in the code segment of the program is removed.

10. The method of claim 6, further comprising an optimizer generating an optimization based on the annotated syntax graph, wherein the optimization comprises a rewrite of at least a portion of the syntax graph.

11. The method according to claim 6, further comprising: An optimizer generates a plurality of optimization candidates, wherein the plurality of optimization candidates are based on the annotated syntax graph; assigning corresponding weights to at least two optimization candidates among the optimization candidates; as well as The optimization candidates are prioritized based at least in part on their respective assigned weights.

12. The method of claim 6, further comprising inserting a callback that, at execution time, triggers a partial evaluation that produces optimizations based at least in part on the annotated syntax graph.

13. The method of claim 6, wherein the ascertaining does not rely on the use of programming language keywords in the source code of the program specifically for indicating the optimization characteristics.

14. The method of claim 6, further comprising updating the catalog to include additional code segments or additional syntax subgraph structures, and updating the catalog to include corresponding optimization properties that match additional annotations of the syntax graph.

15. The method of claim 6, further comprising updating the directory by at least one of: modifying an entry in the directory, deleting an entry from the directory, or changing the order of entries in the directory.

16. A computer-readable storage medium configured with data and instructions that, when executed by a processor, perform a method for finding optimization opportunities during code conversion, the method comprising: scanning at least a portion of a syntax graph of a program, the syntax graph having nodes, the syntax graph representing at least aspects of a grammatical structure of the program; Ascertaining that a code segment of the program associated with a node of the syntax graph has an optimization characteristic; annotating the syntax diagram with an optimization property annotation based on the ascertained optimization property, the optimization property annotation specifying a degree of functional purity of the code segment; consulting a catalog that associates the optimization property annotations with identifications of corresponding portions of the syntax graph of the program, the catalog being distinct from the program and existing before scanning the program syntax graph and after the code transformation of the program is performed; as well as An optimization of the program is generated based at least in part on the annotated syntax diagram.

17. A storage medium according to claim 16, wherein the method also includes forming or locating an optimization property subtree, that is, a set of nodes having the same or inferred associated corresponding optimization properties and also collectively defining a subtree of the syntax graph, the subtree including nodes and connections between the nodes in the set.

18. The storage medium according to claim 16, wherein the method further comprises: Annotating the syntax diagram with possible value annotations that define all possible execution values for code segments, the possible execution values being able to assume different values during different executions of the program, and employing the possible value annotations while generating the optimization of the program.

19. The storage medium of claim 16, wherein the method further comprises at least one of the following: enhancing said source code of said program by adding to the source code a textual representation of a syntax diagram optimization property annotation; or A representation of the syntax graph optimization property annotations in a file derived from and specifically associated with the program is saved for use in subsequent code conversion of a version of the program.

20. The storage medium of claim 16, wherein ascertaining that code F of the program associated with the node of the syntax graph has the optimization property comprises ascertaining that the code F is merely functional code, and for a given set of inputs, executing the code F always provides the same execution result when control is passed from the code F to another code.

Images