Snapshot has originally been introduced for the database [38], but it has also been used to save the state of applications or the virtual machines for diverse purposes.
VMware employs job migration to send an app from the smartphone to the desktop so that the computation is made at the desktop and the result is sent back to the smartphone using the VMware image [19]. However, the VMware is a system VM, which includes the whole Linux image, so the memory overhead would be large for efficient job migration.
Process hibernation saves an intermediate state of the OS booting procedure repeated in every OS booting to reduce the booting time [20]. However, hibernation saves all the processes at once, not suitable to save a single app state.
There is a research work for saving the Java VM state and migrating it [39]. It saves the state of the Java heap and the stack during the interpretation of a Java application. A similar technique would not be applicable to saving an app state though, because it does not deal with app-specific activities such as event handling.
Bellucci et al. [14] proposed to save the JavaScript and the DOM state using the JSON format for app migration. They solved the object reference alias problem similarly to ours. However, they provided no solution to save the closure variables, which occur frequently in real web apps and play an important role for data encapsulation, thus incomplete.
Lo et al. [15] completed the Bellucci’s work by providing a solution to save the closure variables and event handlers. Their solution for closures is adding additional JavaScript code to create a
97
scope object and save the closure variable as a property of the object.
Then, whenever a closure variable is updated in a closure function, the object property is also made to be updated with additional code.
Finally, the scope object is saved as a property of the closure function, which allows retrieving the current value of the closure variable when the closure function is saved in the snapshot. Event handling is also solved using additional code which manages the events using some wrapper functions (otherwise there is no way to access the browser event queue). This instrumentation-based approach is different from ours which accesses the browser and the JavaScript engine internals.
One problem of instrumented app, apart from the instrumentation and space overhead, is that the closure objects that the programmer wants to hide at runtime (they are supposed to exist only at the scope chain of the JavaScript engine) are exposed through the scope objects via global variables, causing a security issue.
There is also a research effort to restore a web app’s state based on capture-and-replay [40]. They log all the events occurred during the app execution, so as to restore the app state by replaying the saved events one by one. This is useful for debugging and performance evaluation. However, restoration can complete only after all saved events are handled, so it would not be appropriate for app migration because the restoration overhead including the file size would be high, proportional to the running time before we capture.
Logging and replaying is done by the client-side JavaScript, but is also done by a modified browser [41].
A limited form of snapshots has previously been exploited for reducing the start-up time of applications.
V8 JavaScript engine employs serialization, which saves the heap where the JavaScript built-in objects created during V8 initialization
98
exist [42]. Now the engine can start faster from the heap with the serialized built-in objects. This is for saving and restoring the initialized state of the JavaScript engine only. The Dart VM also allows saving the pre-parsed data for the classes or methods of Dart libraries and app script for faster app class loading [43].
Unlike V8 and Dart, our snapshot saves the app execution state including those objects created by executing the JavaScript code during app loading such as the framework objects or app objects. Also, we save a state beyond the VM, such as DOM objects, events, or event handlers.
For a Java VM (JVM) environment, romization has been used to serialize the loaded state of system classes including the class block, method block, and the bytecode [44]. This is compiled together with the JVM source code to reduce the class loading time when we launch an application.
There is also a research work to make a JVM process up in advance and to fork a JVM process from it to launch a Java application faster [45]. Actually, Android makes the Zygote process up in advance, which is a Dalvik VM process, where some of the system library classes and framework classes are loaded and initialized [46].
A new Android app is forked from the Zygote which accelerates app loading.
Most snapshot researches for Java or JavaScript VM restore the heap using the snapshot right when the VM starts. Once the heap is restored, it is impossible to add another snapshot of a different app to the existing heap. In fact, these VMs have one-app-per-one-VM execution model, so their snapshot is designed this way. On the other hand, web platforms allow multiple apps to run on a single JavaScript engine. However, V8 serialization is not designed to be addable to an
99
existing heap, either. That is, V8 also restore the heap using the snapshot right when the browser and the JavaScript engine starts.
Once the heap is restored, it is also impossible to add another snapshot of a different app to the existing heap (even if an app- specific snapshot for the app were available). In our snapshot design, however, we can add the snapshot of an app to the existing heap when other apps are running on the same JavaScript engine. Our snapshot can correctly save those objects belonging to an app starting from its window object, and can restore them from the snapshot when other apps are running on the same browser. This is why we do not dump the whole JavaScript heap to the snapshot, but save each object one by one.
100