Real-time migration of running applications between computer systems

Abstract

A first device initiates a template state phase of executing an executable file including a portable bytecode, including providing a deterministic value to a non-deterministic value request. After completing the template state phase, the first device generates a memory snapshot for a set of memory pages used by the executable file. Then, the first device initiates an operational phase of executing the executable file, including generating a memory differential that includes each change to the memory page since the snapshot point. The first device derives the memory delta to the second device. The second device initiates a template state phase of executing the executable file, including providing a deterministic value to a non-deterministic value request. After completion of the template state phase, the second device applies a memory delta to a memory page used by the executable file and continues execution of the executable file.

Description

Background Art

[0001] In computing, an executable file (often referred to as an "executable" or "binary") comprises binary code instructions that are executed by a computer processor. Classically, an executable file contains binary code instructions selected from the instruction set of the target processor instruction set architecture (ISA). As such, these executable files are natively executable on a processor that implements the executable's target ISA. Such executable files are natively executable only on processors that implement the executable's target ISA. Additionally, software typically targets a specific application binary interface (ABI), such as the ABI provided by a specific operating system (OS). In addition to being natively executable only on processors that implement its target ISA, such executable files are also natively executable only on computer systems running an OS that implements the executable's target ABI.

[0002] More recently, executable files include bytecode instructions, a form of instruction set designed to be executed by a software interpreter rather than directly by a processor. The use of bytecode reduces hardware and OS dependencies by allowing the same code to run across different devices with different OS ABIs and different processor ISAs. WebAssembly defines a portable bytecode ISA for developing applications that run on web pages, with a design goal of achieving near-native code execution speed in a web browser. WebAssembly executables can be executed on a variety of OSes and processor ISAs using a runtime environment that includes a low-level virtual stack machine. Although WebAssembly was originally designed for execution within a web browser, it has been applied to more general contexts where its virtual stack machine is embedded into host applications and standalone runtime environments.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is merely provided to illustrate one example technology area where some embodiments described herein may be practiced. Summary of the Invention

[0004] In some aspects, the technology described herein relates to methods, systems, and computer program products, including: obtaining an executable file including portable bytecode; initiating a template state phase of execution of the executable file, including, during the template state phase, providing deterministic values ​​to non-deterministic value requests of the executable file; and, after completing the template state phase, generating a memory snapshot for a set of memory pages used by the executable file; initiating an operation phase of execution of the executable file, including, during the operation phase, generating a memory delta, the memory delta including each change to the set of memory pages since the memory snapshot; and exporting the memory delta.

[0005] In some aspects, the technology described herein relates to methods, systems, and computer program products, including: obtaining an executable file including portable bytecode; obtaining a memory delta for the executable file; initiating a template state phase of execution of the executable file, including providing deterministic values ​​to non-deterministic value requests of the executable file during the template state phase; and after completing the template state phase, applying the memory delta to a set of memory pages used by the executable file; and continuing execution of the executable file after applying the memory delta to the set of memory pages.

[0006] In some aspects, the technology described herein relates to methods, systems, and computer program products, including: a first computer system obtaining an executable file including portable bytecode; the first computer system initiating a template state phase of execution of the executable file, including, during the template state phase, the first computer system providing a deterministic value to a non-deterministic value request from the executable file; and after completing the template state phase, the first computer system generating a memory snapshot for a set of memory pages used by the executable file; the first computer system initiating an operational phase of execution of the executable file, including, during the operational phase, the first computer system presenting a user interface (UI) to a client device; and the first computer system generating a memory delta, the memory delta including a memory delta from the memory. each change to the memory page set since the snapshot; and the first computer system exports the memory delta to the second computer system; and the second computer system obtains the executable file; the second computer system obtains the memory delta for the executable file from the first computer system; the second computer system initiates a template state phase of execution of the executable file, including during the template state phase, the second computer system provides a deterministic value to a non-deterministic value request of the executable file; and after completing the template state phase, the second computer system applies the memory delta to the memory page set used by the executable file; and after applying the memory delta to the memory page set, the second computer system continues executing the executable file; and the second computer system presents a UI to the client device.

[0007] This Summary is provided to introduce some concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To illustrate the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein and, therefore, are not to be considered limiting of their scope, certain systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 An example of a computer architecture that facilitates live migration of running applications between computer systems is illustrated;

[0010] Figure 2 illustrates an example of a live migration component;

[0011] Figure 3 illustrates an example of the timing of live migration of running applications between computer systems;

[0012] Figure 4 A flowchart illustrating an example method for exporting an application execution session; and

[0013] Figure 5 A flow diagram of an example method for importing an application execution session is illustrated. DETAILED DESCRIPTION

[0014] Currently, executable files—including bytecode-based executable programs such as WebAssembly applications—are launched, run, and terminated at a single computer system. Thus, the lifecycle of an execution session of an application occurs entirely on a single computer system. An execution session of an application includes the computer system (e.g., via an operating system or runtime) creating a set of memory pages (e.g., a memory space) for use by the application; the computer system executing the executable's code (e.g., binary code or bytecode) within the context of those memory pages, resulting in changes to the state of those memory pages; and when the application's execution session terminates, the computer system frees those memory pages. Although an application may store some state from its memory pages to persistent storage during its execution (e.g., for use during a later execution session), the contents of the memory pages associated with a given execution session are lost when the session ends.

[0015] At least some embodiments described herein enable running applications to be migrated in real time between computer systems, thereby extending their execution lifecycle on multiple computer systems while providing a seamless user interface (UI) experience. An embodiment initiates execution of an application on a first computer system, including executing a template state phase of an executable file of the application on the first computer system. During this template state phase, an embodiment provides deterministic values ​​to the application for any non-deterministic values ​​requested. As an example, an embodiment provides zero for time requests, zero for random number requests, and a null indicator (e.g., no file exists) for disk access requests. In an embodiment, after the template state phase, the template memory state of the application is snapshotted, and the application continues to execute on the first computer system in an operational phase. Based on the snapshot, the embodiment tracks any changes made by the application to its memory space during this operational phase, thereby generating a memory delta relative to the template memory state of the application that can be exported to a persistent storage device or exported to another computer system.

[0016] The embodiment also initiates execution of the application on the second computer system, including executing a template state phase of the executable file of the application on the second computer system and providing the same deterministic value(s) for any non-deterministic value(s) requested (e.g., a time request, a random number request, a disk access request). By providing the same deterministic value(s) on the second computer system as the deterministic value(s) provided at the first computer system during the template state phase, the memory space of the application at the second computer system reaches a state that is byte-for-byte identical to the template memory state at the first computer system. Notably, executing the template state phase on the second computer system can occur before, concurrently with, or after executing the template state phase on the first computer system.

[0017] Embodiments transfer execution of an application from a first computer system to a second computer system based on a template memory state generated on the second computer system and based on a memory delta generated on the first computer system. Embodiments import the memory delta exported by the first computer system to the second computer system (e.g., by loading the memory delta from persistent storage by receiving the memory delta from the first computer system). Embodiments then apply the memory delta to the memory space of the application on the second computer system, which recreates the changes that the application made to its template memory space during its operational phase of execution on the first computer system. After applying the memory delta to the memory space of the application on the second computer system, embodiments continue to execute the application on the second computer system, effectively migrating the execution session of the application to the second computer system. Some embodiments track further changes that the application makes to its memory space on the second computer system relative to the template memory state, thereby generating a memory delta that can be exported to persistent storage or to another computer system.

[0018] In some embodiments, the first computer system is different from the second computer system. In these embodiments, the first computer system exports the memory delta to the second computer system, and the execution session of the application continues on the second computer system. In these embodiments, after completing the export of the memory delta to the second computer system, the application is terminated on the first computer system.

[0019] In an embodiment, during an operation phase executed on a first computer system, an application sends a UI to a second computer system. Then, during its execution on the second computer system, the application presents the UI at the second computer system. In one example, the first computer system is a server, and the second computer system is a client device (e.g., a desktop, laptop, tablet, or phone). In this example, when executed on the server, the application sends its UI to the client device for remote presentation on the client device. Then, when executed on the client device after the transfer, the application presents the UI on the client device. In another example, the first computer system is a client device, and the second computer system is a server. In this example, when executed on the client device, the application presents the UI on the client device. Then, when executed on the server after the transfer, the application sends its UI to the client device for remote presentation on the client device.

[0020] In other embodiments, the application, whether executed on the first computer system or the second computer system, sends its UI to the third computer system for remote presentation on the third computer system. In one example, the first computer system is a first server (e.g., a regional data center server), the second computer system is a second server (e.g., an edge server), and the third computer system is a client device. In this instance, when executed on the first server or the second server, the application sends its UI to the client device for remote presentation on the client device.

[0021] In an embodiment, in any of these examples, the transition from the UI being presented by the first computer system to the UI being presented by the second computer system occurs within a timeframe that is imperceptible to a human user. Thus, embodiments provide a seamless experience to the user, such that the user is unaware that the application they are interacting with has been transferred from one computer system to another.

[0022] In some embodiments, the first computer system and the second computer system are the same computer system. In these embodiments, the computer system exports the memory differential to a persistent storage device, terminates the execution of the application on the computer system, and later resumes the execution of the application on the computer system based on the persistently stored memory differential. In these embodiments, the application sends its UI to a third computer system for remote presentation at the third computer system. For example, the first computer system and the second computer system are both the same server, and the third computer system is a client device. In this instance, when it is determined that the user is not actively interacting with the application, the server "suspends" the application, thereby freeing up server resources (e.g., memory resources, processing resources). Then, when the user starts interacting with the application again, the server seamlessly "resumes" the application. In some embodiments, the resumption of the application occurs within a timeframe that is imperceptible to a human user, such that the suspension and resumption of the application occur in a manner that is imperceptible to the user.

[0023] In some embodiments, applications can be transmitted between any number of computer systems and in any direction. In one example, a web application begins execution at a regional data center server and sends its UI to a client device. Later, the execution session of the web application is transmitted to an edge server located closer to the client device (e.g., to reduce the latency between the application and the client device, to reduce resource usage at the regional data center server). At some point thereafter, the execution session is transmitted to the client device itself (e.g., to further reduce latency, to reduce resource usage at the edge server). Based on the performance of the application at the client device, it is determined that the functionality of the client device is insufficient to provide a satisfactory user experience, so the execution session of the web application is transmitted back to the edge server and / or regional data center server. In an embodiment, each of these transmissions is seamless to the user of the client device.

[0024] In some embodiments, an application can be suspended / resume at any computer system on which it operates. Continuing with the previous example, after a user has stopped interacting with the web application (e.g., for a predetermined amount of time), the web application's execution session is suspended on the server (e.g., by persisting the memory delta to disk and terminating the application), and later resumed when user activity has resumed (e.g., by launching the web application and executing it through its template state stage and then applying the persisted memory delta). In embodiments, this suspension / resumption is imperceptible to the user of the client device.

[0025] The embodiments herein provide several technical benefits. As just demonstrated, the embodiments enable applications to be migrated in real time between computer systems, which provides the ability to optimize the user experience (e.g., by reducing UI wait times) and provides the ability to manage computer system resources (e.g., by releasing resources at the server computer when the application is migrated away or when the application is suspended). Additionally, the embodiments herein enable server loads to be managed on a per-user (e.g., per-application) basis, thereby allowing a single user's application to be taken offline or migrated away. This is in contrast to other workload migration technologies such as virtual machines, in which the entire logical machine (including the entire operating system and the applications executed thereon) serving multiple users is migrated. Additionally, for developers who want to enable workloads to be converted from one computer system to another, the embodiments herein enable developers to not have to worry about implementing application logic that serializes real-time states.

[0026] Figure 1The diagram illustrates an example of a computer architecture 100 that facilitates live migration of running applications between computer systems. As shown, computer architecture 100 includes computer system 101a and computer system 101b. Each computer system 101a, 101b includes a processor system 102a, 102b (e.g., a single processor or multiple processors); memory 103a, 103b (e.g., system or main memory); storage media 104a, 104b (collectively referred to as storage media 104; e.g., a single computer-readable storage medium or multiple computer-readable storage media); and network interfaces 105a, 105b (e.g., one or more network interface cards), all of which are interconnected via buses 106a, 106b. As shown, computer systems 101a, 101b are interconnected via network 107.

[0027] Storage medium 104a and storage medium 104b are each illustrated as storing computer-executable instructions that implement runtime 108a, runtime 108b (collectively referred to as runtime 108). In an embodiment, these runtimes are the same, although there may be variations (e.g., different versions, focused server versus focused client). Storage medium 104a and storage medium 104b are also each illustrated as storing a corresponding copy of an executable file 110 that is executable within runtime 108. In some embodiments, executable file 110 includes bytecode instructions. While there are various bytecode-based executable file formats, in some embodiments, executable file 110 includes a WebAssembly application. While WebAssembly is provided herein as a specific example, the live migration principles described herein can be applied to a variety of application models and executable file formats, as will be explained below.

[0028] The storage media 104 are each illustrated as storing computer executable instructions that implement a live migration component 109a, a live migration component 109b (collectively, live migration components 109). Similar to the runtime 108, in an embodiment, these live migration components are identical, although variations may exist (e.g., different versions, focused server versus focused client). Figure 1In the illustrated embodiment, live migration component 109 is part of runtime 108. However, in other embodiments, live migration component 109 is separate from runtime 108. In an embodiment, live migration component 109 operates to migrate an application execution session from one computer system to another computer system (e.g., from computer system 101a to computer system 101b, or vice versa) based on executable file 110. In an embodiment, the migration is performed in a manner that provides a seamless UI experience to users interacting with the application. In an embodiment, this means that there is no loss of application state or any visible UI disruption.

[0029] Figure 2 Pictured Figure 1 Example 200 of the live migration component 109. Figure 2 Each internal component of the live migration component 109 depicted in the Figures represents various functions that the live migration component 109 can implement according to the various embodiments described herein. However, it should be understood that the depicted components, including their identities and arrangements, are presented merely as an aid in describing example embodiments of the live migration component 109.

[0030] exist Figure 2 In the embodiment, live migration component 109 includes an executable file transfer component 201. In an embodiment, executable file transfer component 201 obtains an application executable file (e.g., executable file 110) from storage medium 104 or via network 107. Taking computer system 101a and live migration component 109a as an example, in an embodiment, executable file transfer component 201 obtains executable file 110 from storage medium 104a or from computer system 101b when the application is first launched or when the application is being migrated from computer system 101b to computer system 101a. Additionally, in an embodiment, executable file transfer component 201 sends the application executable file (e.g., executable file 110) to another computer system via network 107. Continuing with the example of computer system 101a, in an embodiment, executable file transfer component 201 sends executable file 110 to computer system 101b when migrating the application from computer system 101a to computer system 101b.

[0031] The live migration component 109 also includes a template state component 202. In an embodiment, the template state component 202 controls the template state phase of execution of the application's executable file. During the template state phase of execution, the template state component 202 intercepts non-deterministic application programming interface (API) requests from the application and returns deterministic values ​​for these requests. Examples of non-deterministic API requests include clock read API requests, random number API requests, and disk access API requests. Examples of deterministic values ​​returned for these non-deterministic API requests include returning zero for all clock read API requests, returning zero or the same pseudo-random value for all random number requests, and returning an indication that no file is available for all disk access requests. In an embodiment, the runtime 108 operates to cause the application to execute deterministically to create a fully reproducible memory state anywhere and at any time it runs when the application always receives the same values ​​for non-deterministic API calls during the template state phase. Thus, the template state component 202 enables the application to be executed at various locations (e.g., computer systems) and at various times, while each time generating a set of memory pages (e.g., at least a subset of the application's memory space) that are initialized by the application with byte-for-byte identical contents. In an embodiment, once the application's template state has been reached, the template state component 202 suspends execution of the application (e.g., so that the application's template memory space can be snapshotted).

[0032] WebAssembly is provided herein as an example of an executable file 110 because the WebAssembly application model is created with aggressive application sandboxing features (e.g., as a security feature that limits the damage a malicious WebAssembly application can cause to a client device when running in a web browser at the client device). Due to this aggressive sandboxing, a WebAssembly application can be presented with the same perception of the "outside world" (e.g., outside its sandbox) anywhere and at any time it runs by intercepting non-deterministic WebAssembly System Interface (WASI) calls during the template state phase and providing deterministic values. It is worth noting that other application models may similarly be able to produce applications that can be executed deterministically to create reproducible memory states anywhere and at any time they run. Therefore, the principles of this document are not limited to the use of WebAssembly applications.

[0033] The live migration component 109 also includes a memory snapshot component 203. In an embodiment, after the template state component 202 has initialized the application's memory space and has paused execution of the application in its template state, the memory snapshot component 203 generates and stores a memory snapshot of the application's template memory space, including generating a snapshot copy of each memory page that is part of the application's template memory space. In an embodiment, generating the memory snapshot includes generating a snapshot of the memory page contents. Additionally, in an embodiment, generating the memory snapshot includes generating a snapshot of the memory page metadata (e.g., memory page table entries). Figure 1 , the memory snapshots are represented by memory snapshot 112a and memory snapshot 112b. Notably, because template state component 202 generates byte-for-byte identical content for each instance of a given application, in embodiments, if there are multiple instances of the application running on a given computer system (e.g., instances of the application per user, which may be the case for a web application), memory snapshot component 203 need only generate and store a single instance of a memory snapshot of the template memory space for the application.

[0034] The live migration component 109 also includes a memory delta component 204. In embodiments, the live migration component 109 resumes execution of the application after the memory snapshot component 203 has stored a memory snapshot of the application's template memory space. The memory delta component 204 then generates a memory snapshot delta (memory delta) of any changes that the application made to its memory space during the operational phase of execution. In some embodiments, the memory delta component 204 operates on an ongoing basis during the operational phase of the application. In other embodiments, the memory delta component 204 operates only when it is necessary to export a memory delta for the application (e.g., to persist the runtime state of the application or to migrate the application to another computer system). Figure 1 In FIG, the memory difference is represented by memory difference 113a and memory difference 113b (collectively referred to as memory difference 113). Additionally, Figure 1 In the illustrated embodiment, memory delta 113 may be exported to persistent storage (eg, memory delta 111a , memory delta 111b ).

[0035] In an embodiment, the memory delta component 204 operates based on copy-on-write memory and uses page write tracking (e.g., using the WriteWatch API on Windows or the mprotect API on Linux) to track only deltas from the template memory state. Using these techniques, if there are multiple instances of an application (e.g., each for a different user), each instance of the application is isolated and independent of the other instances; however, these instances do not consume any more memory than is necessary to represent how much the instance has changed from the template. In an embodiment, the memory delta component 204 represents changes to a memory page by applying a bitwise exclusive-OR (XOR) operation between the changed memory page and the corresponding snapshot copy of the memory page. By using the XOR operation in this manner, unmodified regions within the page become highly compressible zero regions that can be compressed using a lossless compression algorithm. In an embodiment, the memory delta 113 represents the memory page changes that are the result of the compression of these XOR operations. Furthermore, the memory delta component 204 applies the memory delta to the template memory page by decompressing the corresponding memory delta and XORing the decompressed result with the template memory page.

[0036] Live migration component 109 also includes a memory delta transfer component 205. In an embodiment, memory delta transfer component 205 obtains memory deltas from storage medium 104 or via network 107. Taking computer system 101a and live migration component 109a as an example, in an embodiment, memory delta transfer component 205 obtains memory deltas 111a from storage medium 104a when resuming an execution session of an application, and imports memory deltas 111a via network 107 when the application is being migrated from computer system 101b to computer system 101a. Additionally, in an embodiment, executable file transfer component 201 exports memory deltas to storage medium 104 or via network 107. Continuing with the example of computer system 101a, in an embodiment, the executable file transfer component 201 persists the memory delta 111a to the storage medium 104a (memory delta 113a) when the execution session of the application is suspended, or exports the memory delta 111a over the network 107 when the application is being migrated from computer system 101a to computer system 101b.

[0037] In an embodiment, the memory delta transfer component 205 transfers the memory delta 113 as an XORed and compressed modified page, as described above in conjunction with the memory snapshot component 203. In an embodiment, this format is sufficiently compressed for efficient transmission so that the changed memory state can be moved across a consumer Internet connection while providing a seamless user experience during the transfer. In an alternative embodiment, the memory delta transfer component 205 transfers a list of bit offsets to toggle within each memory page.

[0038] In an embodiment, the memory delta component 204 and the memory delta transfer component 205 operate in an iterative manner, allowing the user to continue interacting with the application and causing state changes even while the transferred memory delta is in flight. In an embodiment, each time the memory delta transfer component 205 completes a transfer, the memory delta component 204 determines whether another page write has occurred. If so, the memory delta component 204 generates another delta, and the memory delta transfer component 205 sends the other delta. When operating in this manner, each memory delta tends to be smaller than its predecessor as the application tends to reach a steady state. When there are no more pending memory deltas, execution of the application is switched to the target system.

[0039] In an embodiment, the application (e.g., executable file 110) utilizes a UI rendering model that works both locally and remotely (e.g., by using runtime 108 to render a UI based on local or remote UI data). However, in some embodiments, the application does not expose any UI at all.

[0040] Figure 3 An example 300 of timing for live migration of applications running between computer systems is illustrated. Example 300 includes a flowchart 301a of steps performed at computer system 101a (e.g., a server device) and a flowchart 301b of steps performed at computer system 101b (e.g., a client device or even another server device).

[0041] Turning our attention to flowchart 301a and computer system 101a, at step 302 (Obtain Executable), executable file transfer component 201 obtains executable file 110 (e.g., from storage medium 104 or from another computer). At step 303 (Initialization Phase), template state component 202 controls the template state phase of execution of executable file 110, including intercepting non-deterministic API requests and returning deterministic values, and then suspending execution of the application. After step 303, the application has created its template memory state, and at step 304 (Memory Snapshot Generation), memory snapshot generation component 203 generates a snapshot of the template memory state (e.g., memory snapshot 112a). At step 305 (Operation Phase), execution of the application is resumed using the memory deltas generated by memory delta component 204 at step 306 (Memory Delta Generation) and those memory deltas exported to computer system 101b by memory delta transfer component 205 at step 307 (Memory Delta Export). As mentioned, in an embodiment, the memory delta component 204 and the memory delta transfer component 205 operate in an iterative manner so that a user can continue to interact with the application and cause state changes even while the transferred memory deltas are in flight. This is represented by the arrow extending from step 307 to step 306. After all pending memory deltas have been transferred to the computer system 101b (e.g., the application is operating in a stable state with no more memory changes), the application is terminated (suspended / stopped) at step 308.

[0042] Turning our attention now to flowchart 301b and computer system 101b, at step 309 (Obtain Executable File), executable file transfer component 201 obtains executable file 110 (e.g., from storage medium 104 or from computer system 101a). At step 310 (Initialization Phase), template state component 202 controls the template state phase of execution of executable file 110, including intercepting non-deterministic API requests and returning deterministic values, and then pausing execution of the application. After step 303, the application has created its template memory state, and at step 311 (Memory Snapshot Generation), memory snapshot generation component 203 generates a snapshot of the template memory state (e.g., memory snapshot 112b). It is noteworthy that steps 309 to 311 can occur at any time before the end of step 305 at computer system 101a, even before step 302.

[0043] At step 312 (obtain memory delta), the memory delta transmission component 205 obtains memory delta from the computer system 101a. As shown, step 312 can occur at any time before the end of step 305 at the computer system 101a. Thus, for example, the memory delta transmission component 205 can begin obtaining memory delta for the executable file 110 while or even before obtaining the executable file 110. At step 313 (memory delta application), the memory delta component 204 applies the received memory delta to the template state generated by step 310. As shown, once the memory delta application has begun, memory deltas can continue to be received. Once all memory deltas have been received and applied, at step 314 (operation phase), execution of the application continues at the computer system 101b based on the updated memory state.

[0044] Now combine Figure 4 and Figure 5 To describe the embodiment, Figure 4 and Figure 5 Flowcharts are respectively illustrated for an example method 400 for exporting an application execution session and an example method 500 for importing an application execution session. In an embodiment, instructions for implementing the method 400 and the method are encoded as computer-executable instructions (e.g., live migration component 109) stored on a computer storage medium (e.g., storage medium 104a, storage medium 104a), which are executable by a processor system (e.g., processor system 102a, processor system 102b) to cause the computer system (e.g., computer system 101a, computer system 101b) to perform the methods.

[0045] The following discussion now relates to methods and method actions. Although method actions are discussed in a specific order or illustrated in the flowcharts as occurring in a specific order, no specific order is required unless explicitly stated or required because an action depends on another action being completed before performing the action.

[0046] refer to Figure 4 In an embodiment, method 400 includes an act 401 of obtaining an executable file. In some embodiments, act 401 includes obtaining an executable file comprising portable bytecode. For example, at computer system 101a, executable transport component 201 obtains executable file 110 from storage medium 104 or via network 107. Thus, in an embodiment, obtaining the executable file in act 401 includes one of obtaining the executable file from a local persistent storage device or obtaining the executable file from a remote computer system. While various application models can be used, in an embodiment, the executable file is a WebAssembly binary file.

[0047] Although not shown, in an embodiment, method 400 also includes creating an execution environment for the executable file using, for example, runtime 108. In some embodiments, runtime 108 can create multiple runtime instances for the same executable file, such as one runtime instance per user.

[0048] Method 400 also includes an act of executing a template state phase of an executable file 402. For example, executable file transfer component 201 initiates execution of executable file 110. In an embodiment, initiating the template state phase of execution of the executable file includes initiating execution of the executable file within an execution environment.

[0049] Action 402 includes action 403 of providing a deterministic value to a non-deterministic request. In an embodiment, action 403 includes providing a deterministic value to a non-deterministic value request of an executable file during the template state phase. For example, the template state component 202 intercepts API calls (e.g., WASI calls) requesting non-deterministic values ​​and provides deterministic values ​​to those calls. In an embodiment, the template state component 202 intercepts multiple API calls, as indicated by the arrows showing that action 403 can occur repeatedly. In an embodiment, the template state component 202 provides the same deterministic value to each type of non-deterministic call. This means that, in action 403, providing a deterministic value to a non-deterministic value request of an executable file includes providing a deterministic value to multiple non-deterministic value requests having a common request type. Therefore, in an embodiment, providing a deterministic value to a non-deterministic value request of an executable file includes identifying a non-deterministic value request type and identifying a deterministic value based on the non-deterministic value request type.

[0050] Method 400 also includes an act 404 of generating a memory snapshot. In an embodiment, act 404 includes generating a memory snapshot for a set of memory pages used by the executable file after the template state phase is completed. For example, memory snapshot component 203 generates memory snapshot 112a, including a copy of the set of memory pages used by executable file 110 after the initialization phase is completed (e.g., when executable file 110 has created the template memory state based on the operation of template state component 202).

[0051] Method 400 also includes an action 405 of executing an operational phase of the executable file. For example, live migration component 109 resumes execution of executable file 110 after completing the memory snapshot. In some embodiments, during this operational phase, execution of the executable file generates a UI that can be displayed locally (e.g., at computer system 101a) or can be streamed to a remote computer system (e.g., computer system 101b). For example, if computer system 101b is a client device, the UI is streamed to computer system 101b. Therefore, in an embodiment, method 400 includes presenting a UI to a client device during the operational phase of executable file execution.

[0052] Action 405 includes an action 406 of generating a memory delta. In an embodiment, action 406 includes generating a memory delta during the operation phase, the memory delta including each change to the memory page set since the memory snapshot. For example, the memory delta component 204 generates the memory delta 113a during the operation phase in an ongoing manner or upon requesting a migration to the computer system 101b. In an embodiment, generating the memory delta includes tracking each change to the memory page set since the memory snapshot. In an example, the memory delta component 204 operates based on copy-on-write memory and uses page write tracking (e.g., using the WriteWatch API on WINDOWS or the mprotect API on LINUX) to track only the delta from the template memory state snapshotted in action 404. In an embodiment, generating the memory delta includes comparing each memory page in the memory page set that has changed since the memory snapshot with the corresponding snapshot copy. For example, once a memory page change has been detected, the embodiment compares the memory page with the snapshot copy. In an embodiment, comparing each memory page in the set of memory pages that has changed since the memory snapshot with the corresponding snapshot copy includes: for each memory page that has changed since the memory snapshot, using an XOR bitwise operation between the memory page and the corresponding snapshot copy to generate a bit mask. The embodiment may then compress the result using a lossless compression algorithm.

[0053] Act 405 also includes an act 407 of exporting the memory delta. In one example, the memory delta transmission component 205 persists the memory delta 113a to the storage medium 104 (e.g., memory delta 111a). Thus, in embodiments, exporting the memory delta includes persisting the memory delta to a local persistent storage device. In another example, the memory delta transmission component 205 sends the memory delta 113a to the computer system 101b via the network 107. Thus, in embodiments, exporting the memory delta includes sending the memory delta to a remote computer system.

[0054] If combined Figure 3 As described, in an embodiment, generating memory deltas and deriving memory deltas are performed iteratively until changes to the memory page set cease. Figure 4 In FIG. 4 , this is indicated by the arrow extending from action 407 to action 406 .

[0055] refer to Figure 5 In an embodiment, method 500 includes an act 501 of obtaining an executable file. For example, at computer system 101b, executable file transfer component 201 obtains executable file 110 from storage medium 104 or via network 107 (e.g., from computer system 101a). Thus, in an embodiment, obtaining the executable file in act 501 includes one of obtaining the executable file from local persistent storage or obtaining the executable file from a remote computer system. Although various application models can be used, in an embodiment, the executable file is a WebAssembly binary.

[0056] Although not shown, in an embodiment, method 400 further includes creating an execution environment for the executable file using, for example, runtime 108. In some embodiments, runtime 108 can create multiple runtime instances for the same executable file, such as one runtime instance per user.

[0057] Method 500 also includes an act 502 of obtaining a memory delta. In an embodiment, act 502 includes obtaining a memory delta for the executable file. In one example, the memory delta transmission component 205 obtains the memory delta 111b from the storage medium 104 (e.g., loaded into memory as the memory delta 113b). Thus, in an embodiment, obtaining the memory delta for the executable file includes obtaining the memory delta from local persistent storage. In another example, the memory delta transmission component 205 receives the memory delta 113b from the computer system 101a via the network 107 (e.g., the memory delta 113a sent by the computer system 101a). Thus, in an embodiment, obtaining the memory delta for the executable file includes obtaining the memory delta from a remote computer system. As shown, when compared to acts 501 and 503, there is no ordering requirement for act 502. Thus, in an embodiment, act 502 may be performed before act 501, after act 503, or in parallel with act 501 and / or act 503.

[0058] Method 500 also includes executing the template state phase of the executable file act 503. For example, executable file transfer component 201 initiates execution of executable file 110. In an embodiment, initiating the template state phase of execution of the executable file includes initiating execution of the executable file within the execution environment.

[0059] Action 503 includes action 504 of providing a deterministic value to a non-deterministic request. In an embodiment, action 504 includes providing a deterministic value to a non-deterministic value request of an executable file during the template state phase. For example, the template state component 202 intercepts API calls (e.g., WASI calls) requesting non-deterministic values ​​and provides deterministic values ​​to those calls. In an embodiment, the template state component 202 intercepts multiple API calls, as indicated by the arrows showing that action 504 can occur repeatedly. In an embodiment, the template state component 202 provides the same deterministic value to each type of non-deterministic call. This means that, in action 504, providing a deterministic value to a non-deterministic value request of an executable file includes providing a deterministic value to multiple non-deterministic value requests having a common request type. Therefore, in an embodiment, providing a deterministic value to a non-deterministic value request of an executable file includes identifying a non-deterministic value request type and identifying a deterministic value based on the non-deterministic value request type.

[0060] Although not shown, in some embodiments, method 500 includes generating a memory snapshot, such as act 404 of method 400. Thus, in an embodiment, method 500 further includes generating a memory snapshot for the set of memory pages used by the executable file after completing the template state stage.

[0061] Method 500 also includes an act 505 of applying the memory delta. In an embodiment, act 505 includes applying the memory delta to the set of memory pages used by the executable file after completing the template state phase. For example, memory delta component 204 applies memory delta 113b to the memory state generated after act 503. In an embodiment, applying the memory delta to the set of memory pages used by the executable file includes applying an XOR bit mask set to the set of memory pages.

[0062] If combined Figure 3 As described, in an embodiment, receiving and applying the memory delta is performed iteratively until the change of the set of memory pages ceases. Thus, in an embodiment, obtaining the memory delta and applying the memory delta to the set of memory pages used by the executable file are performed in iterative steps.

[0063] Method 500 also includes an action 506 of continuing to execute the executable file. In an embodiment, action 506 includes continuing to execute the executable file after applying the memory delta to the set of memory pages. For example, live migration component 109 resumes execution of executable file 110 based on the memory state applied at action 505.

[0064] In some embodiments, after resuming execution, execution of the executable file generates a UI that can be displayed locally (e.g., at computer system 101b) or streamed to a remote computer system. For example, if computer system 101b is a client device, the UI is displayed locally at computer system 101b. Thus, in an embodiment, method 500 includes presenting the UI to the client device after resuming execution of the executable file.

[0065] In some embodiments, the memory delta component 204 continues to create memory deltas so that the application can be migrated to another computer system or suspended at this computer system. Thus, in an embodiment, after resuming execution of the executable file, the method 500 includes generating a new memory delta that includes each change to the set of memory pages since the memory snapshot and exporting the new memory delta.

[0066] Embodiments of the present disclosure may include or utilize a dedicated or general-purpose computer system (e.g., computer system 101a, computer system 101b) that includes computer hardware, such as, for example, a processor system (e.g., processor system 102a, processor system 102b) and system memory (e.g., memory 103a, memory 103b), as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media accessible by a general-purpose or dedicated computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 104a, storage media 104b). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Thus, by way of example, embodiments of the present disclosure may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0067] Computer storage media is a physical storage medium that stores computer-executable instructions and / or data structures. Physical storage media includes computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) that can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[0068] Transmission media can include networks and / or data links, which can be used to carry program codes in the form of computer-executable instructions or data structures, and which can be accessed by general-purpose or special-purpose computer systems. A "network" is defined as one or more data links capable of transmitting electronic data between a computer system and other electronic devices. When transmitting or providing information to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer system can view the connection as a transmission medium. Combinations are included within the scope of computer-readable media.

[0069] In addition, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be cached in RAM within a network interface module (e.g., network interface 105a, network interface 105b) and then ultimately transferred to the computer system RAM and / or a less volatile computer storage medium at the computer system. Thus, computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0070] Computer-executable instructions include, for example, instructions and data that cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a function or group of functions when executed on one or more processors. Computer-executable instructions can be, for example, binary, intermediate format instructions such as assembly language, or even source code.

[0071] Should be understood that disclosed system and method can be put into practice in the network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, based on microprocessors or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, flat panels, pagers, routers, switches etc. The embodiments of the present disclosure can also be put into practice in a distributed system environment, wherein both local and remote computer systems of a network link (by a hardwired data link, a wireless data link or by a combination of a hardwired data link and a wireless data link) perform tasks. Like this, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in both local and remote memory storage devices.

[0072] It should also be understood that embodiments of the present disclosure can be practiced in a cloud computing environment. The cloud computing environment can be distributed, although this is not required. When distributed, the cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, "cloud computing" is a model for implementing on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The cloud computing model can be composed of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model can also appear in the form of various service models, such as, for example, software as a service (SAAS), platform as a service (PAAS), and infrastructure as a service (IAAS). The cloud computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0073] Some embodiments, such as a cloud computing environment, may include a system that includes one or more hosts capable of running one or more virtual machines. During operation, the virtual machines emulate an operating computing system that supports an OS and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only interfacing with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0074] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts or the order of the acts described above. Instead, the described features and acts are disclosed as example forms of implementing the claims.

[0075] The present disclosure may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects as illustrative and not restrictive. All changes that come within the meaning and range of equivalents of the claims are to be included within their scope.

[0076] When introducing elements in the appended claims, the articles "a," "an," "the," and "said" are intended to mean that there are one or more elements of the element. The terms "comprising / including" and "having" are intended to be inclusive and mean that there may be additional elements in addition to the listed elements. Unless otherwise indicated, the terms "set," "superset," and "subset" are intended to exclude the empty set, and thus a "set" is defined as a non-empty set, a "superset" is defined as a non-empty superset, and a "subset" is defined as a non-empty subset. Unless otherwise indicated, the term "subset" excludes all of its supersets (i.e., the superset contains at least one item not included in the subset). Unless otherwise indicated, a "superset" may include at least one additional element, and a "subset" may exclude at least one element.

Claims

1. A method (400) implemented at a computer system (101a) including a processor system (102a), comprising: Obtaining (201) an executable file (110) including portable bytecode; Initiating (202) a template state phase of execution of the executable file, including: providing deterministic values ​​to non-deterministic value requests of the executable file during the template state phase; and After completing the template state phase, generating (203) a memory snapshot (112a) for a set of memory pages used by the executable file; initiating (204) an operational phase of the execution of the executable file, comprising: during the operational phase, generating a memory delta (113a), the memory delta (113a) comprising each change to the set of memory pages since the memory snapshot; and The memory delta is derived (205).

2. The method according to claim 1, further comprising: During the operating phase of the execution of the executable file, a user interface (UI) is presented.

3. The method of claim 2, wherein presenting the UI comprises: The UI is presented to a client device.

4. The method according to claim 1 , wherein providing the deterministic value to the non-deterministic value request of the executable file comprises: Identifies the non-deterministic value request type; as well as The deterministic value is identified based on the non-deterministic value request type.

5. The method of claim 1 , wherein providing the deterministic value to the non-deterministic value request of the executable file comprises: The deterministic value is provided to a plurality of non-deterministic value requests having a common request type.

6. The method according to claim 1 , wherein generating the memory delta comprises: Each change to the set of memory pages is tracked since the memory snapshot.

7. The method according to claim 1 , wherein generating the memory delta comprises: Each memory page in the set of memory pages that has been changed since the memory snapshot is compared to a corresponding snapshot copy.

8. The method of claim 7, wherein comparing each memory page in the set of memory pages that has been changed since the memory snapshot with the corresponding snapshot copy comprises: For each memory page that has been changed since the memory snapshot, a bit mask is generated using an exclusive OR (XOR) bitwise operation between the memory page and the corresponding snapshot copy.

9. The method of claims 1 to 8, wherein deriving the memory delta comprises one of: persisting the memory difference to a local persistent storage device; or The memory delta is sent to a remote computer system.

10. The method of claims 1 to 9, wherein generating the memory delta and deriving the memory delta are performed iteratively until changes to the set of memory pages cease.

11. A method (500) implemented at a computer system (101b) including a processor system (102b), comprising: Obtaining (201) an executable file (110) including portable bytecode; Obtaining (205) a memory delta (113b) for the execution file; Initiating (202) a template state phase of execution of the executable file, including: providing deterministic values ​​to non-deterministic value requests of the executable file during the template state phase; and After completing the template state phase, applying (204) the memory delta to the set of memory pages used by the executable file; and After applying the memory delta to the set of memory pages, the execution of the executable file continues (109).

12. The method according to claim 11, wherein the method further comprises: After resuming said execution of said executable file, a user interface is presented to a client device.

13. The method according to claim 11 or 12, wherein obtaining the executable file comprises one of the following: Obtain the executable file from a local persistent storage device; or The executable file is obtained from a remote computer system.

14. The method of claims 11 to 13, wherein obtaining the memory delta for the executable file comprises one of: Obtaining the memory difference from a local persistent storage device; or The memory delta is obtained from a remote computer system.

15. The method of claims 11 to 14, wherein providing the deterministic value to the non-deterministic value request of the executable file comprises: Identifies the non-deterministic value request type; as well as The deterministic value is identified based on the non-deterministic value request type.

16. The method of claims 11 to 15, wherein providing the deterministic value to the non-deterministic value request of the executable file comprises: The deterministic value is provided to a plurality of non-deterministic value requests having a common request type.

17. The method according to claims 11 to 16, wherein the method further comprises, after completing the template state stage: generating a memory snapshot for the set of memory pages used by the executable file; after continuing said execution of said executable file, generating a new memory delta comprising each change to said set of memory pages since said memory snapshot; as well as The new memory delta is derived.

18. The method of claims 11 to 17, wherein applying the memory delta to the set of memory pages used by the executable file comprises: A set of exclusive-OR (XOR) bit masks is applied to the set of memory pages.

19. The method of claims 11 to 18, wherein obtaining the memory delta and applying the memory delta to the set of memory pages used by the executable file are performed in iterative steps.

20. A system comprising: A first computer system comprising a first processor system and a first computer storage medium storing first computer-executable instructions, the first computer-executable instructions being executed by the first processor system to at least: Obtaining an executable file including portable bytecode; Initiating a template state phase of execution of the executable file, comprising: providing deterministic values ​​to non-deterministic value requests of the executable file during the template state phase; and After completing the template state phase, generating a memory snapshot for a set of memory pages used by the executable file; Initiating an operation phase of the execution of the executable file, comprising: during the operation phase, Presenting a user interface (UI) to a client device; and generating a memory delta comprising each change to the set of memory pages since the memory snapshot; and exporting the memory delta to a second computer system; and The second computer system includes a second processor system and a second computer storage medium storing second computer-executable instructions, the second computer-executable instructions being executed by the second processor system to at least: Obtaining the executable file; obtaining the memory delta for the executable file from the first computer system; Initiating the template state phase of the execution of the executable file includes: providing the deterministic value to the non-deterministic value request of the executable file during the template state phase; and After completing the template state phase, applying the memory delta to the set of memory pages used by the executable file; and continuing the execution of the executable file after applying the memory delta to the set of memory pages; and The UI is presented to the client device.

Images