Abstract Web applications created using web languages such as HTML, CSS, and JavaScript are widely used regardless of execution environments, owing to their portability and popularity. Since JavaScript language is conventionally used for complex computations in large‐scale web apps, many optimization techniques have been proposed to accelerate the JavaScript performance. However, most of these optimizations speed up JavaScript engines at the expense of consuming more memory. Hence, memory consumption becomes an additional concern in the JavaScript field. Based on the research on memory status, we unearthed that a substantial portion of the heap memory is allocated for JavaScript source code, particularly in lightweight JavaScript engines, which may range from 13.2% to a maximal 52.5% of the entire heap. To resolve this memory issue, this article suggests a new memory optimization method, called dynamic code compression that dynamically compresses the source code and keeps its compressed form instead of the source string. A novel heuristic is proposed to timely compress the source code. We also re‐design the internal structure of the JavaScript engine to efficiently compress the source code without incurring any conflict. Using our code compression method, we could reduce the entire heap memory by up to 43.3% and consistently downsize the overall heap size. From an evaluation of standard benchmarks, our approach showed just 2.7% degradation in performance with negligible compression overhead, proving the feasibility of the code compression technique.

As web pages and web apps increasingly include heavy JavaScript code, JavaScript performance has been a critical issue. Modern JavaScript engines achieve a remarkable performance by employing tiered-execution architecture based on interpreter, baseline just-in-time compiler (JITC), and optimizing JITC. Unfortunately, they suffer from a substantial compilation overhead, which can take more than 50% of the whole running time. A simple idea to reduce the compilation overhead is ahead-of-time compilation (AOTC), which reuses the code generated in the previous run. In fact, existing studies that reuse the bytecode generated by the interpreter or the machine code generated by the baseline JITC have shown tangible performance benefits [12, 31, 41]. However, there has been no study to reuse the machine code generated by the optimizing JITC, which heavily uses profile-based optimizations, thus not easily reusable. We propose a novel AOTC that can reuse the optimized machine code for high-performance JavaScript engines. Unlike previous AOTCs, we need to resolve a few challenging issues related to reusing profile-based optimized code and relocating dynamic addresses. Our AOTC improves the performance of a commercial JavaScript engine by 6.36 times (max) and 1.99 times (average) for Octane benchmarks, by reducing the compilation overhead and by running the optimized code from the first invocation of functions. It also improves the loading time of six web apps by 1.28 times, on average.

JavaScript1 is heavily used in the web, yet it is much slower than other languages. To improve the JavaScript performance, ahead-of-time compilation (AOTC) has been used, either to reuse the bytecode or the machine code generated by the baseline just-in-time compilation (JITC). JavaScript engines today employ high-performance optimizing JITC. So, we propose an AOTC that reuses the code generated by the optimizing JITC. It is more challenging than existing AOTCs since we need to handle more complex address relocation issues. Our preliminary evaluation shows that the proposed AOTC is promising, though.

JavaScript is a dynamic language mainly used as a client-side web script. Nowadays, web is evolving into an application platform with its web apps , and JavaScript increasingly undertakes complex computations and interactive user interfaces, requiring a high-performance JavaScript engine. There have been many optimizations for efficient JavaScript engines, but one component that has not been optimized much is JavaScript parsing . A JavaScript function needs to be parsed before being executed, and the parsing overhead takes a substantial portion of JavaScript execution time for web apps, especially during app loading . This article proposes concurrent parsing of JavaScript, which performs the parsing of JavaScript functions in advance on different threads, while the main thread is executing the parsed JavaScript functions. This can hide the parsing overhead from the main execution thread, reducing the JavaScript execution time, thus reducing the overall app loading time. More specifically, we separated JavaScript parsing and made it run on different threads without violating the execution semantics of JavaScript. We also designed an efficient multi-threaded parsing architecture, which reduces the synchronization overhead and schedules the parsing requests appropriately. Finally, we explored two methods of choosing the target functions for concurrent parsing: one based on profiled information and the other based on speculative heuristics. We performed experiments on the WebKit browser with the JSC engine for real web apps. The result shows that the proposed concurrent parsing can improve the JavaScript performance during app loading by as much as 64% and by 39.7% on average. This improves the whole app loading performance tangibly, by as much as 32.7% and by 18.2%, on average.

Web applications (apps) are programmed using HTML5, CSS, and JavaScript, and are distributed in the source code format. Web apps can be executed on any devices where a web browser is installed, allowing one-source, multi-platform environment. We can exploit this advantage of platform independence for a new user experience called app migration, which allows migrating an app in the middle of execution seamlessly between smart devices. This paper proposes such a migration framework for web apps where we can save the current state of a running app and resume its execution on a different device by restoring the saved state. We save the web app's state in the form of a snapshot, which is actually another web app whose execution can restore the saved state. In the snapshot, the state of the JavaScript variables and DOM trees are saved using the JSON format. We solved some of the saving/restoring problems related to event handlers and closures by accessing the browser and the JavaScript engine internals. Our framework does not require instrumenting an app or changing its source code, but works for the original app. We implemented the framework on the Chrome browser with the V8 JavaScript engine and successfully migrated non-trivial sample apps with reasonable saving and restoring overhead. We also discuss other usage of the snapshot for optimizations and user experiences for the web platform.