Systems and methods for performing binary conversions

Abstract

To translate application binaries from a first execution environment to a second execution environment.SOLUTION: A system comprises: a binary translator comprising a system service executable in a first address space of application binaries and a runtime code module executable in a second address space thereof; and a translation cache stored within a memory, the translation cache storing translations. A given translation corresponds to at least a portion of the application binaries. The translations are for execution in a second execution environment. The translation of the application binaries includes an object-level translation of the application binaries generated prior to the execution of the applications represented by the application binaries. The cached translation of the application binaries within the runtime code module is executed when the operating system requests the execution of the application binaries.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments described herein relate to binary translation, and in particular to caching translated binaries in a translation cache for rapid retrieval by a system service that manages cached translations. [Background technology]

[0002] A standard way for developers to enable an application written for a first execution environment to run in a second execution environment is to port the application to the second execution environment, which involves rebuilding and recompiling the application for the second execution environment. Porting can require significant time and effort for large applications and may require a good working knowledge of the second execution environment and the correct tools to recompile for that execution environment. To bridge the gap while an application is rebuilt and recompiled, developers have often used emulators (e.g., interpreters and / or translators) to execute code on a different execution environment. An interpreter typically iteratively reads application instructions in a first, or source, execution environment and performs operations in the source execution environment that are executed in a software environment within a second, or target execution environment. Other emulators operate similarly but optimize the translation by utilizing some of the underlying hardware of the second environment. For example, an emulator may use the underlying memory and underlying processor and system so that the application appears to be running natively in the second environment, with the application running at a speed determined by the power of the underlying hardware and the performance of the interpreter. The binary translator translates the various instructions and code of the application from a first execution environment to a second execution environment.

[0003] Binary translators can typically be either static or dynamic. A static binary translator attempts to translate all application code from a first execution environment to a second execution environment without actually executing the code beforehand. Dynamic binary translation translates discrete blocks of code during execution and caches the translated blocks for use during the execution of the application that contains that code. The Rosetta dynamic translation layer used to translate PowerPC applications to x86 is an example of a dynamic binary translator. While dynamic binary translators can be more accurate in that they can account for all of the code that requires translation, they often incur greater hardware overhead during application execution due to the dynamic translation, which can cause the application to run more slowly with user-noticeable delays. Furthermore, if the application being translated includes just-in-time (JIT) compilation that requires translation, this will further introduce user-noticeable delays in the application as it undergoes dynamic binary translation. Summary of the Invention

[0004] In one embodiment, a system may include a memory that stores an operating system and one or more application binaries. The one or more application binaries may be written for execution in a first execution environment. The system may further include one or more processors configured to execute the application binaries in a second execution environment different from the first execution environment. The system may also include a binary translator that includes a system service executable in an address space separate from the application binaries and a runtime code module executable in an address space with the application binaries. The system service may be configured to manage translation of the application binaries, and the runtime code module may be configured to manage just-in-time (JIT) translation of application binaries for which the system service lacks a corresponding translation. In one embodiment, the system service may also manage library binaries (e.g., operating system-provided libraries and / or user-provided libraries). The system may further include a persistent translation cache stored in memory. The persistent translation cache may store one or more translations, where a given translation corresponds to at least a portion of one or more application binaries. The one or more transformations may be for execution in a second execution environment, and the transformation of the one or more application binaries may include an object-level transformation of the one or more application binaries generated prior to execution of the one or more applications represented by the one or more application binaries, and the one or more processors may be configured to execute the cached transformation of the one or more application binaries in the runtime code module when the operating system requests execution of the one or more application binaries.

[0005] In one embodiment, the first execution environment can include a source instruction set and the second execution environment can include a target instruction set that differs from the source instruction set. In one embodiment, a code signature can be generated for each page that includes at least a portion of a transformation of one or more application binaries. The data structure that stores the code signature can be encrypted with a key unique to the system (e.g., a secure enclave processor and memory coupled to one or more processors can be configured to generate the unique key). In one embodiment, the object-level transformation can include transformation of libraries used by one or more application binaries during execution. In one embodiment, the object-level transformation can include transformation of plug-ins used by one or more application binaries during execution.

[0006] In one embodiment, a system service may be configured to generate a hash value based on information associated with one or more application binaries. The system service may store the generated hash value in an associative array in memory. The generated hash value may be used to determine whether the one or more application binaries are available in a persistent transform cache and to determine whether the one or more application binaries have been modified. When one or more application binaries have been modified, the system may be configured to remove transforms for the one or more application binaries from the persistent transform cache and generate new transforms.

[0007] In one embodiment, the runtime code module may be configured to determine whether one or more application binaries corresponding to the executing translations have been made writable. When the one or more application binaries have been made writable, the system may be further configured to remove target addresses associated with the one or more application binaries from a global indirect branch table, unlink translations stored in a runtime translation cache that jump directly to the removed translations, advance a global counter, stop execution of threads associated with the one or more application binaries, force the threads associated with the one or more application binaries into just-in-time (JIT) translations of the one or more application binaries performed by the runtime code module, and resume execution of the threads.

[0008] In one embodiment, if one or more application binaries include self-modifying code, the system may be configured to write-protect pages in memory in which the one or more application binaries are stored, trap writes to the protected pages in an exception handler, remove target addresses associated with the one or more application binaries from a global indirect branch table, jump directly to the removed translation, unlink translations stored in a runtime translation cache, advance a global counter, request threads associated with the self-modifying code to process invalidations, perform JIT translations of the self-modifying code, record the global counter value in metadata associated with the translation, update the executing threads with the new version of the global indirect branch table, clean the removed translations from return stacks associated with the executing threads, insert the target address of the branch into the translation via a lookup into the global indirect branch table, and release the translation when all threads have reached the global counter value.

[0009] In one embodiment, a system may include one or more processors configured to execute instructions defined in a first instruction set architecture and a non-transitory computer-accessible storage medium coupled to the one or more processors. The non-transitory computer-accessible storage medium may store: one or more application binaries having instructions defined in a second instruction set architecture different from the first instruction set architecture; a persistent translation cache that stores one or more translated code sequences corresponding to one or more portions of the one or more application binaries, where the one or more translated code sequences, when executed, perform substantially the same operations as the one or more portions of the one or more application binaries; a system service executable in an address space separate from the application binaries; and a binary translator including a runtime code module executable in an address space together with the application binaries. The system service may be configured to manage the persistent translation cache, and the runtime code module may be configured to manage just-in-time (JIT) translation of application binaries for which no translated code sequences are in the persistent translation cache.

[0010] In one embodiment, the system service may be configured to, in response to launching a given application binary of the one or more application binaries, check a persistent translation cache for a corresponding translated code sequence and, based on finding the corresponding translated code sequence in the persistent translation cache, provide the corresponding translated code sequence to the runtime code module. Similarly, a library used by the given application binary may have a translated sequence, and the system service may check the persistent translation cache for a translated library used by the launching application. The translated library may be provided for the launching application binary. Checking the persistent translation cache may be based on a hash value generated based on the given application / library binary. The hash value may differ from a previously generated hash value if the given application binary has been modified since the corresponding translated code sequence was generated. In one embodiment, a first translated code sequence of the one or more translated code sequences in the translation cache is generated when the corresponding application binary is installed on a system. In one embodiment, a first translated code sequence of the one or more translated code sequences in the persistent translation cache is generated when the corresponding application binary is first launched in a system. In one embodiment, a first transformed code sequence of the one or more transformed code sequences in the runtime transformation cache is generated as a JIT transformation of a corresponding application binary when the corresponding application binary was previously launched in the system.

[0011] In one embodiment, a method may include launching a first application binary for execution in a system. The first application binary may be written for a first execution environment, and one or more processors in the system may be configured to execute the application binary in a second execution environment different from the first execution environment. The method may further include determining whether a translated code sequence generated by a binary translator is stored in a persistent translation cache in the system. The binary translator may include a runtime code module executable within the address space of the application binary and a system service executable within a different process, and determining whether the translated code sequence is stored in the persistent translation cache may be performed by the system service. The method may further include performing a just-in-time translation of the first application binary by the runtime code module based on the translated code sequence not being cached in the translation cache. The method may further include executing the cached translated code sequence in the runtime code module based on the translated code sequence being cached in the translation cache. [Brief explanation of the drawings]

[0012] The following detailed description refers to the accompanying drawings, which are briefly described below.

[0013] [Figure 1] 1 is a system including a binary translator according to some embodiments.

[0014] [Figure 2] FIG. 2 illustrates a binary conversion system within the disk storage of the system of FIG. 1 according to some embodiments.

[0015] [Figure 3]FIG. 1 is a diagram of an embodiment of a binary conversion system in system memory during execution, according to some embodiments.

[0016] [Figure 4] 1 is a flowchart illustrating a method for processing cached binary translations according to some embodiments.

[0017] [Figure 5] 10 is a flowchart illustrating a method for processing modifications to binaries associated with cached transformations, according to some embodiments.

[0018] [Figure 6] 1 is a flowchart illustrating a method for processing self-modifying code, according to some embodiments.

[0019] [Figure 7] 10 is a flowchart illustrating a method for processing modifications to an original binary corresponding to a running cached transformation, according to some embodiments.

[0020] [Figure 8] 1 is a flow chart illustrating one embodiment of a method for handling exceptions or other interruptions (code stops) in translated code.

[0021] While the embodiments described in this disclosure may be susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the drawings and detailed description relating to the drawings are not intended to limit the embodiments to the particular forms disclosed, but rather the intent is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the appended claims. The headings used herein are for organizational purposes only and are not intended to be used to limit the scope of the description. DETAILED DESCRIPTION OF THE INVENTION

[0022] Figure 1 illustrates a system 100 including a binary translator, according to some embodiments. As shown in Figure 1, the system 100 includes a processor 102, a main memory 104, input / output (I / O) circuitry 106, a GPU 108, various peripherals 110, and disk storage 112. The processor 102, system memory 104, I / O 106, GPU 108, peripherals 110, and disk storage 112 may be coupled to one another via a bus 114, such that the system components 102-112 are agents of the bus 114.

[0023] Processor 102 may include one or more cores 116-1 through 116-N and processor cache 118. In various embodiments, processor 102 may represent a general-purpose processor that performs computational operations. For example, processor 102 may be a central processing unit (CPU), such as a microprocessor, microcontroller, application-specific integrated circuit (ASIC), or field-programmable gate array (FPGA). Processor 102 may be a standalone component or may be integrated on an integrated circuit with other components (e.g., other processors or other components of a system-on-chip (SOC)). Processor 102 may be a component within a multi-chip module (MCM) with other components.

[0024] Consistent with some embodiments, the processor 102 may be configured to execute instructions defined in an execution environment, such as an instruction set architecture (ISA), implemented by the processor 102 and processor cores 116-1 through 116-N. ISAs may include the original x86 ISA developed by Intel and related x86-64 ISAs developed by AMD and Intel, the ARM and AArch64 ISAs from ARM Holdings, the Power ISA and PowerPC ISA from IBM / Motorola, the RISC-V ISA, and the like. Instructions are defined in an instruction set architecture, including their encoding in memory, their operations, and their effects on registers, memory locations, and / or other processor state. While a given implementation of an ISA may execute each instruction directly, its form may be modified by decoding and other operations within the processor 102. Another implementation may decode at least some instructions into multiple instruction operations for execution by the cores 116-1 through 116-N. Some instructions may, in some embodiments, be microcoded. Thus, the term "instruction operation" may be used herein to refer to an operation that cores 116-1 through 116-N are configured to perform as a single entity. An instruction may have a one-to-one correspondence with an instruction operation, or in some cases, an instruction operation may be an instruction. An instruction may also have a one-to-many (one-to-many) correspondence with an instruction operation. An instruction operation may be more simply referred to herein as an "op."

[0025] Cores 116-1 through 116-N may include various execution units, each configured to perform various types of operations (e.g., integer, floating-point, vector, multimedia, load / store, etc.). Cores 116-1 through 116-N may include different numbers of pipeline stages and various other performance-enhancing features such as branch prediction. Cores 116-1 through 116-N may include one or more of an instruction decode unit, a scheduler or reservation station, a reorder buffer, a memory management unit, an I / O interface, etc.

[0026] The processor cache 118 may be volatile or non-volatile memory. In some embodiments, the processor cache 118 may be static random access memory (SRAM). Additional processor caches may include an instruction cache and a data cache. The processor cache 118 may be organized as a hierarchy of one or more cache levels, such as level 1 (L1), L2, L3, etc.

[0027] Processor 102 may also, in some embodiments, include a secure enclave processor (SEP) 119. The SEP may be a self-contained system-on-chip (SOC) within processor 102 that includes its own processor and one or more security peripherals. SEP 119 may be isolated from the rest of processor 102 so that access to SEP 119 may be strictly controlled. For example, processor 102 may only be able to communicate with SEP 119 through a mailbox mechanism: processor 102 can write messages to the mailbox, and SEP 119 can read and respond to the messages via the mailbox.

[0028] In one embodiment, SEP 119 can manage cryptographic keys for system 100. In one embodiment, software running on system 100 can request a key, and system 100 can generate a "wrapped" key for the requesting software. The wrapped key is encrypted using the wrapping key, and the wrapping key is transmitted in hardware to cryptographic hardware within SEP 119. Using the wrapping key, the receiving cryptographic hardware within the SEP can decrypt the wrapped key provided by the software and obtain the actual key to be used. Insecure software may not have access to the actual key.

[0029] Disk storage 112 may include volatile and / or nonvolatile memory and may function as a long-term storage device for system 100. Disk storage 112 may store one or more applications 120, which, when executed by processor 102, may cause system 100 to perform one or more steps, operations, or functions and may include software applications. Application 120 may comprise one or more binaries. Application 120 may be written for execution in a particular execution environment, such as a particular instruction set architecture. In some embodiments, the execution environment in which application 120 is written is a different execution environment than the execution environment in which processor 102 is designed to execute. In such embodiments, application 120 is considered to be written for a source execution environment, but the processor may execute in a target execution environment. As described throughout, system 100 may be capable of translating application binaries written for a first execution environment, or source execution environment, to application binaries written for a second execution environment, or target execution environment. Returning to FIG. 1, disk storage 112 may include a persistent translation cache 122 and an operating system 124. The operating system 124 may include instructions and frameworks for any well-known operating system, such as MacOS X.

[0030] More generally, disk storage 112 and / or main memory 104 may be examples of computer-accessible storage media. Generally, computer-accessible storage media may include any storage medium that is accessible by a computer when used to provide instructions and / or data to the computer. For example, computer-accessible storage media may include magnetic or optical media, such as (fixed or removable) disks, tapes, CD-ROMs, DVD-ROMs, CD-Rs, CD-RWs, DVD-Rs, DVD-RWs, or Blu-rays. Storage media may also include volatile or non-volatile memory media, such as RAM (e.g., synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), static RAM (SRAM), etc.), ROM, or flash memory. Storage media may be physically installed within the computer from which they provide instructions / data. Alternatively, storage media may be connected to the computer. For example, storage media may be connected to the computer via a network or wireless link, such as network-attached storage. Storage media may also be connected via a peripheral interface, such as a universal serial bus (USB). Generally, a computer-accessible storage medium may store data in a non-transitory manner, where non-transitory, in this context, may mean not transmitting instructions / data over signals. For example, non-transitory storage may be volatile (the stored instructions / data may be lost upon a power-down event) or non-volatile. The computer-accessible storage medium may store various components shown in FIG. 1, such as persistent translation cache 122, applications 120, and / or operating system 124.

[0031] The I / O circuitry 106 and / or peripherals 110 may be any set of additional hardware functions included in the system 100. For example, the peripherals 110 may include video peripherals such as an image signal processor configured to process image capture data from a camera or other image sensor, a graphics processing unit (GPU) such as the GPU 108 shown in FIG. 1 , a video encoder / decoder, a scaler, a rotator, a blender, a video display controller, a display such as a liquid crystal display (LCD) including a display integrated with touch-sensing technology to function as an input device, a light-emitting diode display (LED) such as an organic LED (OLED), a plasma display, etc. The peripherals may include audio peripherals such as a microphone, a speaker, an interface to a microphone and a speaker, an audio processor, a digital signal processor, a mixer, etc. The I / O circuitry 106 may include interface controllers for various interfaces external to the system, including interfaces such as a universal serial bus (USB), a peripheral component interconnect (PCI) including PCI Express (PCIe), serial and parallel ports, etc. The peripherals may include network peripherals such as a media access controller (MAC). Any set of hardware may be included as peripherals 110 and / or I / O circuitry 106. Peripherals may also include other user interface devices such as a keyboard, mouse, or other pointing device.

[0032] Bus 114 may be an example of a communications fabric. In general, a communications fabric may be any communications interconnect and communications protocol for communicating between components of system 100. A communications fabric may be bus-based (e.g., bus 114), including shared bus configurations, crossbar configurations, and hierarchical buses with bridges. A communications fabric may also be packet-based, hierarchical with bridges, crossbar, point-to-point, or other interconnects.

[0033] The main memory 104 may include a memory controller and one or more memory devices. A memory controller typically includes circuitry for receiving memory operations from other components of the system 100 and accessing memory devices to complete the memory operations. The memory controller may be configured to access any type of memory device. For example, the memory device may be static random access memory (SRAM), dynamic RAM (DRAM), such as synchronous DRAM (SDRAM), including double data rate (DDR, DDR2, DDR3, DDR4, etc.) DRAM. Low-power / mobile versions of DDR DRAM (e.g., LPDDR, mDDR, etc.) may be supported. The memory controller may include a queue of memory operations for ordering (and possibly reordering) the operations and presenting the operations to the memory device. The memory controller may also include data buffers for storing write data awaiting writing to the memory device and read data awaiting transmission back to the sender of the memory operation. In some embodiments, the memory controller may include a memory cache for storing recently accessed memory data. In some cases, a memory cache may be referred to as a system cache, as opposed to a dedicated cache, such as processor cache 118, which serves only a particular component. Main memory 104 may store various code for execution, such as applications 120, corresponding translations retrieved from persistent translation cache 122, and operating system 124. In one embodiment, various runtime data structures may also reside in main memory 104. For example, main memory 104 may store global indirect branch table 117.The global indirect branch table 117 may be a data structure managed by the binary translator for mapping indirect branch target addresses from the application 120 to indirect branch target addresses in the corresponding translated code sequence.

[0034] In some embodiments, persistent transformation cache 122 can contain translations of binaries developed or written for one execution environment to a second execution environment that is different from the first execution environment. Binaries can include executables, applications, linkers, libraries, etc. In some embodiments, binaries can include Mach-O objects. In some embodiments, translated binaries stored in the transformation cache can be signed using a key generated by SEP 119 that is unique to system 100, such that a translation is not available to system 100 unless the translation is signed. Furthermore, persistent transformation cache 122 can reside in a read / write partition of disk storage 112 along with operating system 124. More specifically, the translation of a given binary, when executed by processor 102, can cause system 100 to perform substantially the same operations in system 100 that the system would have performed in a system implementing the first execution environment (e.g., ISA) in which the binary was written. Because the second execution environment is different from the first execution environment, there can be some differences in operation. For example, in some cases, multiple instructions in an ISA implemented by processor 120 may be used to perform the same operation as a single instruction in the ISA in which the binary was written. Thus, the amount of time that elapses during execution of the binary may be different compared to executing the original binary in its original execution environment. However, the functionality of the original binary may be maintained identical in, for example, the translated binary.

[0035] 2 is a diagram illustrating a binary translation system 200 within disk storage 112 of system 100, according to some embodiments. As shown in FIG. 2, binary translation system (or simply "binary translator") 200 includes a system service 202 and a runtime code module 204. In some embodiments, runtime code module 204 is a runtime service that resides in an address space corresponding to application 120 within disk storage 112 and is where the translated application 120 executes in a second execution environment. System service 202 may be responsible for managing access to translations stored in persistent translation cache 122 and for managing the coherency of translations stored in persistent translation cache 122 in the case of self-modifying code or other dynamically modified code. System service 202 may manage the scheduling of translations and perform translations when cached translations do not exist or are invalidated. In particular, system service 202 may be responsible for handling calls to persistent translation cache 122, determining hash values ​​associated with one or more binaries 206-1 through 206-N (hereinafter referred to as binaries 206) of application 120, writing them to global hash table 208, and performing lookups therefrom. In some embodiments, system service 202 may handle requests to binary translator 202 via inter-process communication (IPC) calls from operating system 124. Runtime code module 204 may be responsible for handling just-in-time (JIT) translations and may also be responsible for monitoring the state of registers updated by the application during execution (e.g., registers defined within the source ISA or execution environment in which application 120 was originally written).

[0036] 2, application 120 includes application binaries 206. As previously described, binaries 206 may include executables, applications, linkers, libraries, etc. In some embodiments, binaries 206 may include Mach-O objects. In some embodiments, disk storage may further include shared libraries and / or shared caches 210 that may store libraries and caches that may be utilized by multiple applications, services, and / or operating system 124 itself.

[0037] In some embodiments, binaries 206 may be translated when installed on system 100 via a standard or trusted installation process associated with operating system 124. The translation process may be performed as part of installation (e.g., installation may not be complete until translation is complete) or as a background process during and / or after installation. For other installations, such as sideloading or via removable disk media, binary translator 200 may translate binaries 206 upon first launch of application 120 or first use of any binary 206. If a binary 206 cannot be translated due to a translation failure caused by a misformation or misprediction, runtime code module 204 includes a just-in-time (JIT) translation process that translates a smaller set of instructions associated with that binary 206 when system 100 attempts to execute application 120. When operating system 124 is being updated, system service 202 may delete all cached translations in persistent translation cache 122 and initiate a background process to retranslate all previously cached binaries 206. Additionally, when the binary translator 200 is added to the system 100 , the binary translator 100 can translate the shared libraries and shared cache 210 associated with the operating system 124 .

[0038] To perform the conversion of a binary written for execution in a first execution environment for use in a second execution environment, system services 202 can identify one or more entry points into binary 206 to determine potential portions of the binary that may require code conversion. In some embodiments, the first execution environment can include support for variable-size instructions, and the second execution environment can include support only for fixed-size instructions. In these embodiments, system services 202 may not know instruction boundaries based on the size of the instructions, and so can find potentially valid instructions for conversion in multiple steps along the way. System services 202 may identify entry points into binary 206 using information provided by a static linker for the dynamic linker. In particular, in some embodiments, operating system 124 can include a dynamic linker that links applications to shared libraries 210 and places specific code at address points in disk storage 112 where application 120 is coded at link time, allowing application 120 to use machine-specific calls or jump instructions to one of those address points when it needs to utilize the dynamic linker instead of interacting with the dynamic linker directly. System service 202 can utilize these specific address points as entry points to identify code that requires translation. Once the entry points are identified and the code that requires translation is identified, system service 202 can translate the identified code written for the first execution environment into code that is executable in the second execution environment. System service 202 can save the translation to persistent translation cache 122 in disk storage 112 and update associative array 208 by performing a hash of application binary 206 and storing the hash in array 208.

[0039] 3 is a block diagram illustrating one embodiment of main memory 104 in operation. Various portions of the address space may be mapped by operating system 124 as system service space 320 and user (or non-privileged) space 322. For example, operating system 124 may define pages of memory as privileged space or user space 322 in the virtual-to-physical address translation mechanism as one of the page attributes in the translation. The privileged space may be the address space in which operating system 124 itself executes, or at least the kernel portion of operating system 124 in a kernel-based embodiment. User space 322 may be the space in which application 120 executes. System service space 320 may also be user space, but may be separate from the address space in which translated applications execute (e.g., system services may be a different process from the translated application, but runtime code module 204 may execute in the translated application's address space). In general, code executing within user space 322 may not be permitted to execute certain instructions that control critical processor state that operating system 124 reserves for itself.

[0040] As mentioned above, the system service 202 can execute within the system service space 320 and maintain the persistent transformation cache 122. The persistent transformation cache 122 can be within the user space so that the transformed code can be executed by the processor 102, but access to the persistent transformation cache 122 can be controlled by the system service 202 (e.g., generating a hash and checking the transformation when a given application 120 is invoked for execution). Alternatively, a transformation from the persistent transformation cache 122 can be mapped into memory when the corresponding application is launched or when an entry point corresponding to the cached transformation is invoked. The transformation may be loaded into memory, and a pointer to the transformation may be provided to the runtime code module 204. The transformation can be loaded into the address space of the application within the user space 322. If multiple threads are executing the same transformation, the transformation may be mapped into each thread's address space. Alternatively, the threads may share a common copy of the transformation. There may also be other times when the transformation is loaded from the persistent transformation cache 122. For example, a dynamic linker can link various dynamically linked libraries to an application. If the dynamically linked library is being written for a first execution environment, the dynamic linker can request that the runtime code module 204 determine whether a translation is available in the persistent translation cache 122. The runtime code module 204 can query a system service to determine whether a translation is available and can determine the size of the translation. Alternatively, the dynamic linker can query the system service and provide the size to the runtime code module to allocate memory for the translated library. The dynamic linker can load the original library code and request that the runtime code module 204 load the corresponding translation and provide a pointer to the translation.

[0041] As described above, runtime code module 204 executes in user space 322 (or, more specifically, in the address space of application 120 if application 120 is written in an ISA different from the ISA of processor 102). Runtime code module 204 may maintain a runtime translation cache 122 for JIT translations generated by runtime code module 204 when a corresponding translation or portion thereof for application 120 is not found in persistent translation cache 122.

[0042] In one embodiment, the JIT transformations generated by the runtime code module 204 can also be installed as transformations in the persistent transformation cache 122. While JIT transformations often cover small portions of the application 120 that are dynamically generated as the application executes, when the JIT transformations begin to cover a sufficiently large portion of the entire application (e.g., a threshold amount), the JIT transformations may be installed in the persistent transformation cache 122 by the system service 202 and retained for execution at a later time. In other embodiments, the JIT transformations may not be installed in the persistent transformation cache 122 and may therefore be generated by the runtime code module 204 each time the corresponding application is invoked. In yet another embodiment, the generation of the JIT transformations can serve as a hint to the binary translator 200 to consider the transformations to be installed in the persistent transformation cache 122. If the binary translator 200 determines that a transformation should be executed, the binary translator 200 can execute the transformation separately from the JIT transformation and install the separately generated transformation in the persistent transformation cache 122. Various factors can determine whether a JIT transformation causes a transformation in the persistent transformation cache 122 (e.g., how often the JIT transformation is used or how often it is generated over time during different runs of the application, whether the JIT transformation is due to self-modifying code, which may not be installed in the persistent transformation cache 122, etc.).

[0043] The shared libraries / cache 210 may also be in user space 322 or in a privileged space or combination of spaces (e.g., the libraries 210 may be in a privileged space or in user space 322 on a library-by-library basis).

[0044] FIG. 4 is a flowchart illustrating a method 400 for processing cached binary translation, according to some embodiments. As shown in FIG. 4, when application 120 is invoked (step 402), a check may be made to determine whether application 120 was written for a first execution environment (step 404). In some embodiments, an application, such as application 120, may include one or more binaries 206 written for execution in a first execution environment, such as x86 or x86-64, which requires a processor capable of executing those instructions. If application 120 is not written for the first execution environment and is instead capable of running natively within a second execution environment, which may be, for example, ARM or AArch64, application 120 may run natively (step 406). If application 120 is written for the first execution environment, it may be passed to system service 202 of binary translation system 200 (step 408). In some embodiments, code for passing the application to system service 202 may be part of runtime code module 204. The system service 202 may calculate a hash value based on metadata associated with one or more binaries 206 of the application and / or the binaries 206 themselves, and compare the generated hash to one or more hash values ​​in the associative array 208 to determine whether a cached translation exists in the persistent translation cache 122 or whether the expected cached translation is not available (step 410). If a match is found in the array 208, the cached translation may be used by granting (by the system service 202 to the runtime module 204) access to the cached translation. The cached translation may be mapped into memory (e.g., into the application's user address space 322 as shown in FIG. 3) using standard operating system calls (step 412).The translated application binary may then be executed in a second execution environment within the runtime code module 204 (step 414). If the hashes do not match, the application 120 may not have been previously translated. In this case, the system service 202 may initiate a background process to translate the application binary 206 (step 416) and install the resulting translation into the persistent translation cache 122. In parallel, the runtime code module 204 may generate a JIT translation of the code for the current execution. The JIT translation may be executed in the second execution environment within the runtime code module 204 (step 414).

[0045] FIG. 5 is a flowchart illustrating a method 500 for processing modifications to a binary associated with a cached translation, according to some embodiments. As shown in FIG. 5, when application 120 is invoked (step 502), a check may be made to determine whether the application was written for a first execution environment (step 504) (e.g., similar to the embodiment of FIG. 4). In some embodiments, an application, such as application 120, may include one or more binaries 206 written for execution in a first execution environment, such as x86 or x86-64, which requires a processor capable of executing those instructions. If application 120 is not written for the first execution environment and instead is capable of running natively within a second execution environment, which may be, for example, ARM or AArch64, the application may run natively (step 506). If the application is written for the first execution environment, it may be passed by runtime code module 204 to system service 202 of binary translation system 200 (step 508). The system service 202 may calculate a hash value based on metadata associated with one or more binaries 206 of the application or the binaries 206 themselves and compare the hash to one or more values ​​in the associative array 208 to determine whether a cached translation exists in the persistent translation cache 122 or whether the application has been modified (step 510). If a match is found in the array 208, the cached translation may be used by granting access to the cached translation, which may then be mapped into memory for that particular application using standard operating system calls (step 512). The translation may be executed in a second execution environment using the runtime code module 204 (step 520). If the hashes do not match, the application 120 may have been modified and require a new translation.In this case, the system service 202 may remove the cached translation (step 514), and the system service 202 may generate a new translation (step 516), which may then be sent to the runtime code module 204 (step 518) for execution within a second execution environment within the runtime code module 204 (step 520).

[0046] Consistent with some embodiments, the binary translation system 200 can also manage multithreaded resources. In some embodiments, the runtime code module 204 can use a particular time-based process to manage its resources, known as epoch-based reclamation. In epoch-based reclamation, each thread of execution on the system 100 can be associated with a current epoch that indicates when the thread last exited the runtime code module 204 and discarded any pointers to shared state. Threads can asynchronously request that other threads advance their epochs or perform one of a small number of tasks. When all threads have advanced to a sufficiently recent epoch, the shared resources can be deallocated.

[0047] FIG. 6 is a flowchart illustrating a method 600 for handling self-modifying code, according to some embodiments. Some execution environments, e.g., x86 and x86-64, allow applications to employ self-modifying code, and binary translation system 200 may also be capable of handling self-modifying code. In some embodiments, a first execution environment may actively maintain coherence between a data cache and an instruction cache, as well as between an instruction pipeline, which may invoke the self-modifying code as it is generated. To handle such self-modifying code, binary translation system 200 may first write-protect any code pages in memory of binaries 206 written for a first execution environment that have been converted to code written for a second execution environment (step 602). Then, if a write occurs, which may be either a store instruction or an attempt to modify that page in memory via a system call, etc., system service 202 may trap the write to an exception handler in runtime code module 204 (step 604). The exception handler in runtime code module 204 may then remove any branch targets to that page from global indirect branch table 117 (step 606) and unlink any translations that jump directly to the affected translation (step 608). The exception handler may then advance a global epoch counter (step 610), asynchronously request that all other threads process this code invalidation (step 612), and record the advanced global epoch counter value in metadata for each affected translation (step 614). When processing the asynchronous requests, the other threads update to the latest version of indirect branch table 117, clean the removed translations from their return stack caches (or simply clear the entire cache) (step 616), and enter the translated code by performing a new lookup from indirect branch table 117 (step 618). Execution of the original thread may then continue with the trapping of the write.Once all other threads have reached the newly updated epoch, the affected transformations are released from the lock and can proceed to execution (step 620). Note that method 600, in one embodiment, may be processed by runtime code module 204 within the application's address space.

[0048] FIG. 7 is a flowchart illustrating a method 700 for processing modifications to an original binary corresponding to an executing cached translation, according to some embodiments. As shown in FIG. 6, when a cached translation is executing within the runtime code module 204 (step 702), the runtime code module 204 may determine that the original binary corresponding to the currently executing cached translation has been made writable (step 704). In some examples, the application 120 corresponding to the cached translation may modify the binary 206 during execution by making the binary writable, indicating that the binary is likely to be modified, thereby invalidating any previously cached translations of the binary 206. An exception handler within the runtime code module 204 may then remove any branch targets to that page from the global indirect branch table 117 (step 706) and unlink any translations that jump directly to the affected translation (step 708). In one embodiment, the binary translator 200 may maintain a mapping from the original (untranslated) code address, which is the translation entry point, to the corresponding translation itself. The mapping enables the binary translator 200 to efficiently execute ordered queries. When the affected translations are invalidated for code writes in a given page, mappings for any addresses in that age can be invalidated. The exception handler can advance a global epoch counter (step 710). The runtime code module 204 can then send a message to the operating system 124 to stop all execution threads (step 712). The runtime code module 204 can then check whether any threads were executing cached translations, and if so, the runtime code module 204 forcibly redirects them to the JIT translations generated by the runtime code module 204 (step 714).For example, the thread-specific context of each thread may include a variable that indicates the last global epoch change that the thread observed. The variable may be atomically written by a thread and atomically read by other threads. The runtime code module may resume execution of all threads in a second execution environment within the runtime code module 204 (step 716). In some embodiments, the JIT transformations are not cached in disk storage 112, but are only temporarily stored within the writable address space of the runtime code module 204.

[0049] In some embodiments, the binary translation system 200 can also handle indirect branches. In particular, indirect branch lookup can be performed using a global indirect branch table 117, allowing multiple threads to read the table without synchronization, but with a lock held by the writer to modify the table. As the size of the table 117 grows, only threads that update their local table pointers to point to the latest version get the new version; this occurs as needed when a thread returns to translated code from the runtime code module 204. In some embodiments, reuse of older table 117 versions (after the table has grown) is handled using epoch-based reuse. Because the table 117 is linearly probed, evictions may be handled in-place. A race condition exists where one thread may evict while another is reading, resulting in a falsely detected cache miss. This can be handled by having the persistent translation cache 122 miss code path acquire the same lock used by the writer. A function return is a specific type of indirect branch that can be handled by using a software version of a return stack branch predictor. A pair of the program counter from the first execution environment and the translated program counter for the second execution environment is stored on the stack. On return, the return address is checked to see if it matches the stored address associated with the program counter of the first execution environment, and if so, the saved translated program counter is returned. Otherwise, the indirect branch operation proceeds normally.

[0050] In some embodiments, when system 100 executes translated application 120, runtime code module 204 may improve the accuracy of the translation by monitoring the execution of the translated instructions to ensure that exceptions, traps, and other interruptions in instruction execution occur at instructions in the target execution environment that correspond to the beginning or ending of instructions in the source execution environment (“instruction boundaries”). That is, a given instruction in the source ISA may be translated into multiple instructions in the target ISA. If instruction execution in a translated instruction sequence is interrupted at one of the instructions that does not represent a source instruction boundary, the register state and / or other architectural state of processor 102 may reflect partial execution of the source ISA instructions, which is not possible on a processor that natively executes the source ISA. For example, operating system 124 may include various mechanisms for interrogating registers after stopping execution in a translated instruction sequence (e.g., for debugging purposes). The runtime code module 204 can monitor execution of the translated instructions to ensure that at every point in execution in the second execution environment, the runtime code module can fast-forward or rewind execution by a small number of instructions to produce the correct register state according to the first execution environment as if the binary were actually executing exactly with respect to the instruction boundaries observed in the first execution environment. In some embodiments, this process can enable execution of the translated instructions to appear to execute atomically as if they were executed within the first execution environment instead of being executed in the second execution environment using instructions designed for the second execution environment.

[0051] 8 is a flow chart illustrating one embodiment of a method 800 for handling exceptions or other interruptions (code stops) in translated code. An exception may be a synchronous stop of code due to a condition detected with respect to an executing instruction. An interrupt may in some cases be asynchronous with instruction execution (e.g., an external interrupt sourced from a device or an interrupt issued by another thread). An interrupt occurs when an instruction completes execution, but may be independent of the execution of that instruction. When exceptions and interrupts occur during execution of translated code, they occur between translated instructions but may not occur at the instruction boundary of the corresponding source instruction because there may be multiple translated instructions used to emulate the source instruction.

[0052] Thus, the translation is performed (step 802). If a code stall is not detected (decision step 804, "no" branch), translation execution can continue (step 802). On the other hand, if a code stall is detected (decision step 804, "yes" branch), runtime code module 204 can inspect the code sequence to determine whether the code stall occurred at a source instruction boundary (step 806). For example, in one embodiment, binary translator 200 can generate the translation according to a set of rules, such that by inspecting the code sequence (disassembling instructions near the stall), binary translator 200 can determine where the boundaries of a given source instruction are and what the progress of the source instructions was at the time of the stall. If the stall occurred at an instruction boundary (decision step 808, "yes" branch), the stall can be processed at the instruction boundary (step 816). If not (decision step 808, "no" branch), the runtime code module 204 may determine whether any architectural state of the source execution environment has been modified (and whether the modifications can be reversed to restore the state at the start of the source instruction) (decision step 810). If the architectural state has not been modified, or if the architectural state has been modified and reversal is possible and desirable rather than rolling forward (decision step 810, "no" branch), the runtime code module 204 may roll the state back to the beginning of the source instruction (step 820), or an abort may be processed (step 816). If the architectural state has been irreversibly modified, or if a rollback is undesirable (decision step 810, "yes" branch), the runtime code module may determine whether a roll forward is possible through the runtime code module 204 emulating the remainder of the source instruction execution and modifying the architectural state with the results of the instruction (decision step 812).If roll forward is possible (decision step 812, "yes" branch), the runtime code module 204 may roll forward to the next instruction boundary (block 814), and the stop may be processed at that instruction boundary (step 816). If roll forward is not possible (decision step 812, "no" branch), execution of the translated code sequence may terminate (step 818).

[0053] This disclosure includes references to "one embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or examples of the disclosed concepts. References to "an embodiment," "one embodiment," "particular embodiment," etc. do not necessarily refer to the same embodiment. Numerous possible embodiments, including those specifically disclosed, as well as modifications or alternatives that are within the spirit or scope of this disclosure, are contemplated.

[0054] This disclosure may discuss potential advantages that may result from the disclosed embodiments. All implementations of these embodiments necessarily exhibit some or all of the potential advantages. Whether advantages are realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are many reasons why an implementation within the scope of the claims may not exhibit some or all of any disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of this disclosure that, in conjunction with one of the disclosed embodiments, negates or reduces one or more of the disclosed advantages. Furthermore, suboptimal design practices of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce a disclosed advantage. Even assuming skilled practice, realization of advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, inputs provided to a particular implementation may prevent one or more problems addressed in this disclosure from occurring on a particular occasion, resulting in the benefits of that solution not being realized. Given the existence of factors external to the present disclosure that may arise, it is expressly intended that any potential advantages described herein should not be construed as claim limitations that must be met to demonstrate infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to a designer having the benefit of the present disclosure. The fact that such advantages are permissibly described (e.g., a statement that a particular advantage "may result") is not intended to convey any doubt as to whether such advantage can actually be realized, but rather to recognize the technological reality that realization of such advantages often depends on additional factors.

[0055] Unless otherwise specified, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of claims made based on this disclosure, even if only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative, not limiting, unless a statement to the contrary is present in the present disclosure. The above description is intended to enable claims that cover not only the disclosed embodiments, but also alternatives, modifications, and equivalents that will be apparent to those skilled in the art having the benefit of this disclosure.

[0056] For example, features of the present application may be combined in any suitable manner. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority to this application) for any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with features of other dependent claims as appropriate, including claims that are dependent on other independent claims. Similarly, features from each independent claim may be combined as appropriate.

[0057] Thus, the accompanying dependent claims may each be drafted to depend on a single other claim, although additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with this disclosure is contemplated and may be claimed in this or another application. In short, combinations are not limited to those specifically recited in the accompanying claims.

[0058] Where appropriate, it is contemplated that a claim drafted in one format or statutory type (e.g., apparatus) is also intended to support a corresponding claim in another format or statutory type (e.g., method).

[0059] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. The public is hereby notified that the definitions provided in the following paragraphs, as well as throughout this disclosure, will be used in interpreting the claims made based on this disclosure.

[0060] Reference to a singular item (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more" unless the context clearly indicates otherwise. Thus, a reference to an "item" in a claim does not exclude additional instances of the item without context. A "plurality" of an item refers to a set of two or more items.

[0061] The word "may" is used herein in a permissive sense (i.e., having the possibility, being able to do), not in an obligatory sense (i.e., not required).

[0062] The terms "comprising" and "including" and their variations are open-ended and mean "including, but not limited to."

[0063] When the term "or" is used in this disclosure in reference to a list of alternatives, it will generally be understood to be used in an inclusive sense unless the context clearly indicates otherwise. Thus, a list of "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, the phrase "either x or y, but not both" makes clear that "or" is used in an exclusive sense.

[0064] The enumeration of "w, x, y, z, or any combination thereof," or "...at least one of w, x, y, and z" is intended to encompass all possibilities, including single elements, up to the total number of elements in the set. For example, for the set [w, x, y, z], these expressions encompass any single element of the set (e.g., w but not x, y, or z), any two elements (e.g., w and x but not y or z), any three elements (e.g., w, x, and y but not z), and all four elements. Thus, the phrase "...at least one of w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby encompassing all possible combinations of this list of elements. This phrase should not be interpreted as requiring that there be at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0065] In this disclosure, various "labels" may precede nouns or noun phrases. Unless the context clearly indicates otherwise, various labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Furthermore, when applied to features, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise specified.

[0066] As used herein, the phrase "based on" is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence the decision. That is, the decision may be based solely on the specified factors, or on the specified factors as well as other unspecified factors. Consider the phrase "determining A based on B." This phrase identifies B as a factor used to determine A or that influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. This phrase is intended to cover embodiments in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0067] The phrases "in response to" and "in response to" describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, either together with the particular factor or independently of the specified factor. That is, the effect may depend only on these factors, or on the specified factor as well as other unspecified factors. Consider the phrase "performing A in response to B." By this phrase, B is a factor that triggers the execution of A or triggers a particular result for A. This phrase does not exclude that the execution of A may also be in response to other factors, such as C. This phrase also does not exclude that performing A may be in response to both B and C. This phrase is intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to."

[0068] Within this disclosure, various entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. This phrase "entity" configured to perform one or more tasks is used herein to refer to a structure (i.e., a physical thing). More specifically, this phrase is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform a task even if the structure is not currently operating. In this manner, an entity described or explained as being "configured" to perform a task refers to a physical thing, such as a device, a circuit, a system having a processor unit and a memory storing executable program instructions to perform the task. This phrase is not used herein to refer to an intangible thing.

[0069] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations, and even if not specifically described, it will be understood that those entities are "configured to" perform those tasks / operations.

[0070] The term "configured to" is not intended to mean "configurable to." For example, an unprogrammed FPGA is not considered to be "configured" to perform a particular function. However, this unprogrammed FPGA may be "configurable" to perform that function. After appropriate programming, the FPGA can then be said to be "configured" to perform a particular function.

[0071] For purposes of filing a U.S. patent application based on this disclosure, reciting a structure as "configured to" perform one or more tasks in a claim is not expressly intended to invoke 35 U.S.C. §112(f) for that claim element. If an applicant wishes to invoke 35 U.S.C. §112(f) during prosecution of a U.S. patent application based on this disclosure, it would recite a claim element using "means for" [performing a function].

[0072] Various "circuits" may be described in this disclosure. These circuits or "circuitry" comprise hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom designed or obtained from standard libraries. In various implementations, circuitry may include digital components, analog components, or a combination of both, as appropriate. Particular types of circuits may be generally referred to as "units" (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units are also referred to as circuits or circuitry.

[0073] The disclosed circuits / units / components and other elements shown in the drawings and described herein include hardware elements such as those described in the preceding paragraphs. Often, the internal arrangement of hardware elements within a particular circuit can be specified by describing the function of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing the opcode of an instruction and routing the instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured to" perform this function. This specification of this function is sufficient to suggest a set of possible configurations of the circuit to one skilled in the computer arts.

[0074] In various embodiments, as discussed in the previous paragraph, circuits, units, and other elements are defined by the functions or operations they are configured to perform. The arrangement of such circuits / units / components relative to one another and the way they interact ultimately generates a microarchitecture definition of hardware that is fabricated within an integrated circuit or programmed into an FPGA to form the physical implementation of the microarchitecture definition. Thus, a microarchitecture definition is recognized by those skilled in the art as a structure from which many physical implementations can be derived, all of which belong to the broader structure described by the microarchitecture definition. That is, a person skilled in the art presented with a microarchitecture definition provided in accordance with this disclosure can, without undue experimentation, implement the structure by coding the circuit / unit / component description into a hardware description language (HDL), such as Verilog or VHDL, using ordinary techniques. HDL descriptions are often expressed in a manner that appears to be functional. However, to those skilled in the art, this HDL description is the method used to translate the structure of a circuit, unit, or component into the next level of implementation detail. Such HDL descriptions may take the form of behavioral code (which is typically not synthesizable), register transfer language (RTL) code (which, in contrast to behavioral code, is typically synthesizable), or structural code (e.g., a netlist specifying logic gates and their connections). The HDL description may be synthesized against a library of cells designed for a given integrated circuit manufacturing technology and modified for timing, power, and other reasons, resulting in a final design database that can be sent to a foundry to generate masks and ultimately manufacture the integrated circuit. Some hardware circuits, or portions thereof, may also be custom designed in a schematic editor and incorporated into the integrated circuit design along with the synthesized circuit. An integrated circuit may further include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between the transistors and the circuit elements.Some embodiments may implement multiple integrated circuits connected together to realize the hardware circuit, and / or some embodiments may use discrete elements. Alternatively, the HDL design may be integrated into and implemented in a programmable logic array, such as a field programmable gate array (FPGA). This decoupling between the design of circuits and the subsequent low-level implementation of those circuits generally results in a scenario where the circuit or logic designer does not specify any particular set of structures for the low-level implementation other than a description of how the circuit is configured, since this process is performed at a different stage in the circuit implementation process.

[0075] The fact that many different low-level combinations of circuit elements can be used to implement the same specification for a circuit results in numerous equivalent structures for that circuit. As noted above, these low-level circuit implementations may vary depending on variations in manufacturing technology, the foundry selected to manufacture the integrated circuit, the library of cells provided for a particular project, etc. In many cases, the choices made by different design tools or methods to generate these different implementations may be arbitrary.

[0076] Furthermore, for a given embodiment, it is common for a single implementation of a circuit's particular functional specifications to include a large number of devices (e.g., millions of transistors). Thus, this absolute amount of information makes it impractical to exhaustively enumerate the low-level structures used to implement a single embodiment, let alone the vast number of equivalent possible implementations. For this reason, this disclosure describes the structure of a circuit using functional abbreviations used in the industry.

[0077] Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated, and it is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. 1. A system comprising: a memory storing one or more application binaries, the one or more application binaries written for execution in a first execution environment; one or more processors configured to execute application binaries in a second execution environment different from the first execution environment; A binary translator, managing the conversion of said application binaries; a binary translator configured to manage just-in-time (JIT) translation of the application binaries for which the binary translator lacks a corresponding translation; a transformation cache stored within the memory and configured to store one or more transformations, a given transformation corresponding to at least a portion of the one or more application binaries, the one or more transformations being for execution in the second execution environment; The binary translator is configured to determine whether the one or more application binaries corresponding to the translation have been made writable, and if the one or more application binaries have been made writable, the system: removing the target address of the translation associated with the one or more application binaries from the global indirect branch table; unlinking a translation stored in the translation cache that jumps directly to the removed target address; stopping the execution of threads associated with the one or more application binaries; forcing the thread associated with the one or more application binaries to JIT translate the one or more application binaries; The system is further configured to resume the execution of the thread.

2. 10. The system of claim 1, wherein when the one or more application binaries are made writable, the system is further configured to advance a global counter used to deallocate shared resources, the global counter being shared by multiple threads.

3. the binary translator is further configured to maintain a mapping of untranslated code addresses that are translation entry points to corresponding translations; 10. The system of claim 1, wherein the system is further configured to invalidate the mapping of untranslated code addresses associated with the one or more application binaries when the one or more application binaries are made writable.

4. 2. The system of claim 1, wherein after resuming the execution of the thread, the JIT translations for the thread are not stored in the translation cache.

5. 2. The system of claim 1, wherein the one or more processors are configured to execute the cached translation of the one or more application binaries within a binary translator runtime code module that determines whether the one or more application binaries corresponding to the ongoing translation are made writable.

6. The system of claim 5 , wherein the exception handler of the runtime code module removes translations associated with the one or more application binaries from the global indirect branch table.

7. The binary translator system service generating a hash value based on information associated with the one or more application binaries; 2. The system of claim 1, configured to: store the generated hash values ​​in an associative array in the memory, the generated hash values ​​being used to determine whether the one or more application binaries are available in the translation cache and to determine whether the one or more application binaries have been modified.

8. The system of claim 1 , wherein the transformation of the one or more application binaries is signed using a key unique to the system.

9. The system of claim 1 , wherein the transformation of the one or more application binaries is encrypted with a key unique to the system.

10. a secure enclave processor coupled to the one or more processors and the memory, the secure enclave processor configured to generate the unique key; The system of claim 8 or 9, further comprising:

11. 2. The system of claim 1, wherein the transformation of the one or more application binaries comprises an object-level transformation of the one or more application binaries generated prior to execution of one or more applications represented by the one or more application binaries.

12. The system of claim 11 , wherein the object-level transformation includes transformation of libraries used by the one or more application binaries during execution.

13. 1. A computer-implemented method, the method comprising: launching a first application binary for execution in a system, the first application binary being written for a first execution environment, and one or more processors in the system being configured to execute the application binary in a second execution environment different from the first execution environment; determining whether a translated code sequence produced by a binary translator is stored in a translation cache within the system; executing the cached transformed code sequence based on the transformed code sequence being cached in the transformation cache; In response to the binary translator determining that the first application binary has been made writable, removing a target address of a translation associated with the first application binary from a global indirect branch table; unlinking a translation stored in the translation cache that jumps directly to the removed target address; Stopping the execution of a thread associated with the first application binary; forcing the thread associated with the first application binary into a just-in-time (JIT) translation of the first application binary; resuming the execution of the thread; A method comprising:

14. In response to the binary translator determining that the first application binary has been made writable, advancing a global epoch counter shared by a plurality of threads; The method of claim 13 further comprising:

15. maintaining a mapping of untranslated code addresses that are translation entry points to corresponding translations; In response to the binary translator determining that the first application binary has been made writable, invalidating the mapping of untranslated code addresses associated with the first application binary; The method of claim 13 further comprising:

16. 14. The method of claim 13, wherein determining whether the translated code sequence is stored in the translation cache is based on a hash value generated based on the first application binary.

17. 14. The method of claim 13, wherein after resuming the execution of the thread, no JIT translations for the thread are stored in the translation cache.

18. The method of claim 13 , wherein the converted code sequence is generated when the first application binary is first installed on the system.

19. The method of claim 13 , wherein the translated code sequence is generated when the first application binary is first launched on the system.

20. 14. The method of claim 13, wherein the transformed code sequence is generated as a JIT transformation of a corresponding application binary when the corresponding application binary was previously launched on the system.

Images