Introduction

JavaScript is a popular and versatile programming language that is the de facto standard for web development. It is also infamously known to be hard to analyze statically due to its dynamic nature. And so, insights into the behavior of JavaScript programs must often be gathered dynamically. In practice, only so-called "lightweight" dynamic program analyses, such as code coverage and profiling, are commonly deployed. Nonetheless, there exists another class of so-called "heavyweight" dynamic analyses. Examples include: taint analysis which is capable of detecting violations of security policies, and concolic testing which is capable of automatically generating test cases. These analyses share the need to track values at run-time especially primitive values -e.g., tracking strings such as password data is crucial for taint analysis. This is commonly achieved through a technique called shadow execution, which involves mirroring part of the program state with meta information. Although these heavyweight dynamic analyses have their merits, they are rarely used in practice. We hypothesize three main reasons for this lack of adoption: Narrow Applicability: Academic approaches are often unsuitable for real-world deployment because they depend on a modified JavaScript runtime. While this may be effective for controlled experiments on a specific corpus of programs, it is typically impractical for real-world scenarios. JavaScript is deployed across a diverse and rapidly evolving ecosystem of runtimes, both on the client and server sides. For broader adoption, analyses must be applicable across a wide range of use cases.

Complex Customization: Heavyweight dynamic analyses are inherently complex and demand a high level of customization to yield meaningful results. For example, taint analysis involves specifying sources and sinks, while concolic testing requires mechanisms to generate new inputs. To encourage adoption, such analyses must offer an expressive interface that supports extensive customization while remaining concise and easy to understand.

BENEVOL24: The 23rd Belgium-Netherlands Software Evolution Workshop, November 21-22, Namur, Belgium laurent.christophe@vub.be (L. Christophe); coen.de.roover@vub.be (C. De Roover); wolfgang.de.meuter@vub.be (W. De Meuter) https://lachrist.github.io (L. Christophe); https://soft.vub.ac.be/~cderoove (C. De Roover) 0009-0001-5294-0585 (L. Christophe); 0000-0002-1710-1268 (C. De Roover); 0000-0002-5229-5627 (W. De Meuter)

aran's Overview

The main idea behind aran is to express analysis as logic. So during analysis, two layers will coexist inside the same JavaScript program: the layer of the program under analysis, which we call the base layer and the layer of the analysis, which we call the meta layer. A natural way to weave the logic of the analysis into the target program is to rely on aspect-oriented programming [1] which entails expressing the logic of the analysis in JavaScript as well. In this paradigm, behaviors which are collectively called advice are inserted at execution points called join points according to a specification called pointcut. This action is called weaving. The combination of an advice and a pointcut is called an aspect. Hence, in our approach, an analysis is expressed as an aspect. In Listing 1, we present a simple aspect that logs the call stack of a program by inserting logic around every function application of the target program. aran focuses on weaving the user analysis into the target program by performing source code transformation while the actual deployment is left to the user. This is a design choice that we made to ensure that the approach remains broadly applicable. Indeed, integrating an analysis into a build system or a CI/CD pipeline is a non-trivial task and goes beyond the scope of this paper. We envision two main architectures for deploying aran.

First is offline deployment, which is depicted in Figure 1. In this architecture, the analysis happens in two separate processes that run sequentially. In the first process, the target program is instrumented based on the pointcut of the analysis, and the setup code is generated. Then, these two parts are bundled with the advice of the analysis, which creates a standalone JavaScript program. The analysis will be performed once this program is executed as it would have been originally. This architecture is useful to reduce the memory footprint and performance overhead of the analysis.

Second is online deployment, which is depicted in Figure 2. In this architecture, everything happens in a single JavaScript process. That is, the runtime must be parameterized to preload aran and instrument the target program at load-time. This architecture is more likely to impact the behavior of the target program and requires engine parameterization, but it enables instrumentation of dynamically generated code. While global code does not necessarily need to be instrumented, code evaluated by a direct eval export const initialState = { depth: 0 }; export const aspect = { pointcut: ["apply@around"], advice: { "apply@around": (state, callee, thisArgument, argumentList, path) => { state.depth += 1; try { console.log(".".repeat(state.depth) + " >> " + callee.name + " at " + path); const result = Reflect.apply(callee, thisArgument, argumentList); console.log(".".repeat(state.depth) + " << " + callee.name + " at " + path); return result; } catch (error) { console.log(".".repeat(state.depth) + " !! " + callee.name + " at " + path); call imperatively does. Otherwise, the base layer of the target program will be able to access the meta layer of the analysis. It follows that direct eval calls are only supported in this architecture.

We are aware that these architectures are work-intensive for the user. In the future, we plan to investigate how relevant functionalities could be provided for common workflows. For instance, offline architecture could benefit from a CLI that would expect a selection of files to instrument and would bundle the standalone JavaScript program. And the online architecture could benefit from a tool able to parameterize various JavaScript runtimes to instrument the target program at load-time.

aran's Intermediate Language

Instead of directly weaving the analysis logic in JavaScript, our approach performs weaving in an intermediate language instead. If weaving were to be performed directly in JavaScript, the aspectoriented API would require such a high number of different join points that it would make the approach hard to customize. This is due to the fact that JavaScript has become quite a complex language over the years. Indeed, since 2015, the TC39 committee, which is in charge of maintaining ECMAScript -i.e., the de facto standard specification of JavaScript -has accelerated the rate at which new features are introduced and switched to a yearly release cycle. While this has kept JavaScript fresh and relevant, it has also rendered it more difficult to analyze. Our intermediate language is called aran-lang and was designed with the following three criteria in mind:

Minimal: aran-lang should be as simple as possible to enable the user to express complex analyses that require shadow execution in a clear and concise manner. The ultimate goal of aran-lang is to restore the core simplicity of JavaScript, but it is constrained by the other two criteria.

JavaScript Subset: aran-lang should be reasonably close to a subset of JavaScript so that aran's API remains understandable to JavaScript developers. We do not want developers to have to study this intermediate language to be able to properly use our approach.

Expressive: aran-lang should be sufficiently expressive to support the full ECMAScript specification without requiring excessive additional logic. Indeed, while additional logic is necessary to express complex features using simpler ones, it should be kept to a minimum to reduce code bloat and performance overhead. Also, this additional logic will look unfamiliar to the end user of the analysis and could make the results of the analysis hard to interpret.

Being an intermediate compilation language, aran-lang does not require an actual syntax. Instead, in Appendix B, we present the AST format of aran-lang as a TypeScript type definition. In the remainder of this section, we discuss several points of interest regarding the language.

Strict Mode Only JavaScript can be executed in two modes: strict mode and sloppy mode. In strict mode, some errors are thrown instead of being ignored, and some features, such as the with statement are disabled. These features are often considered legacy and preclude JavaScript runtimes from carrying out important optimizations. We made the design decision to always output instrumented code in strict mode. While this completely hides the complexity of dealing with two modes from the user, it forces us to remove all the sloppy-only features of JavaScript from aran-lang.

Intrinsic Record Often, logic added by aran involves accessing pre-existing values from the global object. These values are usually referred to as intrinsic values. For instance, the regexp literal /pattern/u can be expressed as new • RegExp("pattern","u"). In doing so, we have to ensure that the variable RegExp still refers to the intrinsic %RegExp%. In aran-lang, intrinsic values can be retrieved by name with No Imported Variable In a JavaScript module, values from external modules are imported as local variables. These variables are one-way bound to the external value -i.e., they are locally immutable, but mutations from within their source module are reflected. Hence, they can be viewed as syntactic sugar for their external location and be removed from the local scope. In aran-lang, this is made explicit by ImportExpression, which contains a Source and a Specifier.

No Exported Variable In a JavaScript module, local variables can be exported, and any modification to those variables will be visible from other modules. In aran-lang, this coupling is made explicit through an ExportEffect which contains a Specifier for the name of the export and an Expression for the new value of the export. Note that export operations are made into effects for the same reason as write operations.

Explicit Variable Hoisting

In JavaScript, variables are actually declared earlier than where their declaration appears. This process is referred to as hoisting and is a common source of confusion. In aran-lang, variables are always declared at the beginning of the block where they are hoisted. This translates in aran-lang by the absence of declaration statements and the presence of a list of bindings in RoutineBlock and ControlBlock. An important behavior that we had to recreate is the temporal deadzone. This timing window spans the moment from where a variable is hoisted to where the declaration statement actually resides. Accessing variables in this temporal deadzone should result in a run-time error, which we implemented through run-time checks. Note that variables in aran-lang have no kind, and that their immutability is also enforced with run-time checks.

Static Variable Access

In JavaScript, different types of dynamic frames can reside in a scope. The global object which is at the root every scope and the global declarative record which sits just after the global object are both important instances of dynamic frame. However, the with construct and direct calls to %eval% can also introduce dynamic frames. In aran-lang, we decided to make the scope static by reifying dynamic frames. Combined with immutability checks and deadzone checks, this means that read and write operations cannot throw exceptions and cannot trigger arbitrary code. This is an important property of aran-lang because it enables the analysis to not check for the result of these operations.

Hard-Coded Parameter Set

For the sake of simplicity, aran-lang does not allow for parameter renaming. Instead, all parameters have a fixed name. Some of these parameters already exist in JavaScript -e.g., this, new.target, and import.meta. Some other parameters had to be introduced -e.g., function.callee, function.arguments, and catch.error. We introduced function.arguments to replace the traditional arguments parameter for two reasons: it is sometimes missing, and it is plagued by legacy features -e.g., 'arguments.callee' and index binding with parameters. Finally, some parameters are functions that are introduced to simplify the language and its associated weaving API -e.g., import for representing dynamic import expressions. However, this is not a silver bullet because the analysis must still reason about the meaning of these functions.

Explicit this Argument JavaScript implements object-oriented programming by passing a hidden argument that is assigned to the this parameter. In aran-lang, the this argument is explicitly provided to ApplyExpression. Thus, xs.map(f) becomes something like apply((_this_=xs).map,_this_,[f])1 .

Mandatory Result Value

In JavaScript, programs complete with a value based on their last value statement, and functions return a value provided by an optional return statement. Because this behavior is hard to reason about, aran-lang represents the body of these two constructs as a RoutineBlock, which is parameterized by an expression that is evaluated last and provides the result value of the program or the function. break statements are used to model the control flow of return statements.

Preserved Generator Head

In JavaScript, the code in the parameters of functions can be arbitrarily complex. Our parameter system allowed us to move that logic into the body of functions, which simplifies analysis. Unfortunately, we were not able to apply this simplification for generator functions. This is because the code in the parameters of generator functions is not executed at the same time as the code in its body 2 . Consequently, we had to add an array of Effect nodes into RoutineBlock to store the head of generator functions.

aran's Aspect-Oriented API

The main parameter of the weaving process is the pointcut, which can be seen as a predicate for deciding which join points should be intercepted. There is another important option that dictates whether the instrumented code should access the built-in original global declarative record or use a plain object that reifies it. To preserve the safety of variable access, if the built-in global declarative record is used, global variables will be accessed with custom intrinsic functions such as %aran.readGlobal%. These functions become unnecessary if the global declarative record is emulated. This is an advantage because the advice will not have to reason about these aran-specific intrinsic functions. However, emulating the global declarative record requires instrumenting every single bit of code from the target program to ensure the emulation is not bypassed. As selective instrumentation is an important feature, we envisioned both options.

Interestingly, the logic of the analysis is not directly woven into the target program. Instead, the advice is called by the instrumented code and is expected to adhere to the advice interface presented in Appendix A. Because aran-lang was designed to enable shadow execution, this interface is almost a one-to-one mapping with the aran-lang AST format. The only weaving that is not straightforward is related to blocks:

• First, analyses should be able to reason about the scope and should receive a reified frame upon entering each block. This is provided as a mapping from local variables and parameters to initial values. Variables declared with the var and function keywords are initialized with the %undefined% intrinsic while variables declared through the let and const keywords are initialized with the %aran.deadzone% intrinsic. Reified block frames are provided to both block@declaration and block@declaration-overwrite. These two join points are similar, but the latter enables the analysis to overwrite the initial value of a variable which is useful for analysis based on wrappers.

• Second, analyses should be able to reason about control flow. To that end, we provide the block@throwing join point which is triggered when the block throws an exception. And, we provide the block@teardown join point which is triggered upon exiting the block regardless of how it terminated. If either of these join points is intercepted, the block will have to be wrapped inside a try statement.

To facilitate state management, every single advice receives a local state as the first argument. This local state can be updated upon entering a block with the block@setup advice. This makes it easy to implement list-like data structures and mirror the scope of the program. Local states are also useful for restoring the context of the analysis after a hiatus in the control flow caused by yield and await expressions.

To locate the AST node that triggered the advice, every single advice receives the path of its triggering node as the last argument. More precisely, this argument is a string that represents the chain of properties leading to the triggering node -e.g., "$.body.0.expression". Other approaches, such as Jalangi [2], use indices instead. While indices should be faster in theory, they also make the overall interface more complex. We decided this was not worth the performance improvement which is likely to be minor thanks to optimizations such as string interning. Listing 2: The shadow state of our track-origin analysis.

To evaluate the expressiveness of our approach, we implemented an analysis called track-origin that records the execution tree of run-time values 3 . This analysis can be leveraged to carry out analyses based on symbolic execution such as concolic testing. Our analysis consists of approximately 300 LoC and can handle all the corner cases of JavaScript. Listing 2 defines the state of the analysis as a TypeScript type definition that mirrors both the value stack and the scope. The code of the analysis is clear and concise; the only logic that we needed to implement involved the transient tracking of shadow values before and after calls to instrumented functions.

It remains an open question whether our API is suitable for implementing analyses truly on a per-project basis. In the negative, we could introduce a domain-specific language for defining the analyses. Alternatively, we could provide a suite of JavaScript APIs, each designed for a specific class of heavyweight dynamic analysis.

Evaluating aran Against Test262

To evaluate the reliability of our approach, we implemented it in a tool 4 5 and tested it against Test2626 , which is the official conformance test suite of ECMAScript. It contains about 50, 000 test cases that cover the entire ECMAScript specification and even upcoming proposals. We conducted our experiment on the setup described in Table 1. It consists of applying increasingly complex instrumentation to Test262 cases. At every stage, we excluded the test cases that failed in the previous stages. This helped us to triage failures and diagnose bugs. We describe below our six instrumentation stages 7 ; each based on the online architecture depicted in Figure 2.

1. engine: Leaves test cases intact. This stage is intended to uncover the technical limitations of either the underlying node runtime or our custom test runner. It also provides a basis to compute the slowdown factors for subsequent stages.

Laurent Christophe et al.

CEUR Workshop Proceedings 1-18

Hardware Apple Air M2, 2022 node Version v22.3.0 Test262 Commit SHA: 18ebac81 8 aran Commit SHA: 664f0a30 9 acorn Version 8.12.1 10 astring Version 1.9.0 11

Table 1

Setup for testing aran against Test262 3. main-min: Applies minimal aran instrumentation to the main file of each test case. Test fixtures, module dependencies, and dynamic global code are not instrumented. However, dynamic local code must be instrumented at the eval@before join point which is the only pointcut of this stage. Note that even though weaving is minimal, the source code undergoes many during its transformation from JavaScript to aran-lang.

4. full-min: Still applies minimal aran instrumentation, but on every single bit of the code of each test case. This provides us with the opportunity to test the emulation of the global declarative record. This requires advising not only eval@before but also apply@around and construct@around to intercept and instrument dynamic global code provided to the %eval% intrinsic and %Function% intrinsic. Note that this simple access control system does not intercept indirect applications of intrinsic functions -e.g., eval.call("code").

part-max:

Applies maximal aran instrumentation to the main file of each test case. In this stage, every join point is advised by a function that contains no logic. -e.g., apply@around is advised by (ste,fct,ths,args)=>Reflect.apply(fct,ths,args).

6. track-origin: Our analysis for recording the execution tree of run-time values as presented in Section 4. It is applied to the main file of each test case.

Figure 3 depicts an overview of the results of our experiment. (i) Stage engine introduces about 15k failures, which corresponds to a failure rate of about 12%; by far the highest. Most of these failures were due to features that have not yet been implemented in node such as the new Temporal API, which accounts for more than 4k failures. Other failures were due to our test runner not entirely adhering to the interface prescribed by Test262 12 . For instance, some parts of this interface relate to inter-realm communication which occurs via built-in function calls. Whereas, we are interested in preserving the semantics of syntactic constructs. We also discovered actual bugs in node, and we reported some of them 13 14 15 . (ii) Stage parsing introduces 198 failures, which were mostly due to acorn not correctly handling corner cases. (iii) The failures introduced by subsequent stages which actually deploy aran are limited in number (143). They provide a good overview of the limitations of our tool as they highlight the semantics that we were not able to preserve. We discuss these discrepancies below and their incidence on the observed failure count.

• Missing iterable return in pattern (42 ⇒ 29%): Array destructuring assignments -e.g., [x0,x1]=xs -are carried out via the iterable protocol 16 . It prescribes calling the return method of the iterator when exiting the destructuring assignment; regardless of its outcome. However, after aran instrumentation, this method will not be called if an exception is thrown during the iteration. This semantics is challenging to restore because destructuring assignments occur in an expression context and cannot be directly wrapped in a try statement.e

• Corrupt code reification (34 ⇒ 24%): There exist two ways for JavaScript programs to inspect their own source code: the stack property of Error instances and the toString method of %Function.prototype%. After instrumentation by aran, these two mechanisms will provide a representation of the instrumentation code instead of the original code. This semantics could be restored with some engineering effort. However, we decided against it because the ECMAScript specification does not actually specify the output format of these two mechanisms. As a result, code reification is not guaranteed to be stable across different JavaScript engines and is primarily used for debugging purposes. One might wonder how this discrepancy accounted for 34 failures since it is not part of the specification. The reason is that two functions with the same source code should cause %Function.prototype.toString% to produce the same string. Unfortunately, this is not guaranteed after instrumentation because of the compilation variables introduced by aran.

• No two-way bindings for arguments (32 ⇒ 22%): In sloppy mode, functions with a simple list of parameters will have them two-way bound with the arguments object. This means that changes to the arguments object are reflected in the values of the parameters and vice versa. In a previous version of our tool, we preserved this behavior by leveraging the Proxy API [3]. However, we decided to remove this feature because it caused performance overhead and because dynamic argument binding is considered legacy.

• Hoisted root declarations (20 ⇒ 14%): To simplify its API, aran hoists export declarations and variable declarations to the beginning of the sources. Although the temporal deadzone is enforced inside the source, other sources will be able to bypass it. For modules, this is only an issue in the case of circular dependencies. For scripts, this is only an issue if the script synchronously executes another script that uses its own declared global variables. Additionally, because the value of global const declarations is not available, aran has to turn global const declarations into let declarations. Although the immutability of the variables will be enforced in the current source, other sources will be able to bypass it.

• No dynamic function properties (2 ⇒ 1%): Functions created in sloppy mode contain two properties that change dynamically as the function is being called: arguments and caller. We decided not to preserve this feature because it is technically challenging and because these properties have been deprecated (although they are still part of the ECMAScript 2024 specification). • Other Discrepancies (13 ⇒ 9%): We observe other discrepancies that require code that is so convoluted that it is unlikely to cause issues in practice. For instance, after aran instrumentation of a derived class, the prototype property of the parent class is accessed twice instead of once. This could be observed with a getter or with the Proxy API. A detailed list of the discrepancies can be found in the repository of our tool 17 .

To prevent flakiness, Test262 was designed to be independent of performance. However, performance overhead is the discrepancy most likely to cause issues in practice. Indeed, as the performance overhead of the analysis increases, so does the chance that time-sensitive applications will be affected. For instance, some event interleaving might be observed by the analysis, whereas such interleaving may never occur without it. To provide insight into the performance overhead of our approach, we recorded the time required to execute each test case in each stage. Figure 4 depicts the distribution of slowdown factors that were observed in each stage compared to the initial engine stage. It appears that slowdown factors rarely exceed 10x, which is corroborated by the total time of each stage shown in Figure 3.

Although not depicted in Figure 3, outliers can reach a slowdown factor of up to 800x. They were removed from the graph because they made it hard to read. We selected the set of pathological test cases that made the slowdown factor of stage part-min exceed 100x. This selection contains 32 test cases, among which 31 were large and probably generated files of several thousands lines of code -e.g., 18 . This made us suspect that the overhead was largely due to the instrumentation. Figure 5 depicts the distribution of the time spent instrumenting code compared to the total time required to execute each test case. It appears that instrumentation accounts for about half of the time required to execute a typical test case. However, Figure 6 depicts the same data but only for the pathological selection. It appears that instrumentation accounts for almost all the time required to run a pathological test case. This is a positive outcome because instrumentation overhead can be lifted by performing instrumentation statically via the offline architecture depicted in Figure 1.

We are aware that Test262 is not tailored to benchmark performance. Hence, the 10x slowdown factor we observed is a crude approximation of how our approach could perform in practice. Further work is required to establish the transparency of our approach for real-world time-sensitive applications. 17 https://github.com/lachrist/aran/blob/664f0a30/doc/issues/missing-iterable-return-call-in-pattern.md 18 https://github.com/tc39/test262/blob/867ca540/test/language/identifiers/start-unicode-10.0.0-class-escaped.js

Related Work

Driven by the popularity and dynamic nature of JavaScript, the research community has proposed a wealth of approaches for dynamically analyzing JavaScript programs. By far, the most successful class of dynamic program analysis for JavaScript is the so-called "lightweight" dynamic analyses such as: code coverage 19 , profiling [4, 5] 20 , and dynamic linting [6, 7, 8]. In this section, we briefly review the state-of-the-art approaches that are capable of supporting shadow execution of JavaScript and implementing so-called "heavyweight" dynamic analyses.

Linvail Most importantly, the work we presented in this paper iterates on previous work presented in [9]. While this earlier work also relies on source code instrumentation to carry out shadow execution, it focuses on an interesting technique called membrane, which involves using the Proxy JavaScript API [3] to enforce an access control system between instrumented and non-instrumented code areas. This membrane was leveraged to track primitive values for longer periods of time. This approach was implemented in a library 21 which can still be integrated into our approach. This paper proposes several novelties. First, we came up with an aspect-oriented API to define the logic of the analysis which is more flexible than our previous API. Second, we crafted an intermediate language that strikes an interesting balance between expressiveness and simplicity. Third, we confronted our approach against the complexity of the ECMAScript specification.

Jalangi Apart from our own work, the closest related work is Jalangi [2]. It is another approach for building heavyweight dynamic analyses through JavaScript source code instrumentation. It is however unclear how Jalangi can handle the current complexity of JavaScript. While the first version of Jalangi 22 has been archived, the second version of Jalangi 23 is still maintained. However, is has not kept pace with ECMAScript's fast release cycle as it only supports ECMAScript 5.1 24 which dates back to June 2011. Dynamic Taint Analysis A prime application of shadow execution is dynamic taint analysis which enforces security policies at run-time by propagating security-related labels along with run-time values. As security is an important concern for JavaScript programs, multiple taint analysis approaches have been proposed [10, 11, 12]. Most of these approaches rely on a modified runtime to carry out the analysis. While runtime instrumentation is attractive for conducting experiments, we believe it is not suitable for wide adoption. In contrast, our tool is based on source code instrumentation and is designed to be deployed on any JavaScript runtime. To the best of our knowledge only Ichnaea [12] is based on source code instrumentation. There are two major differences between their work and ours. First, they provide an API that forces the user into a specific shadow execution model optimized for taint analysis, whereas we provide a flexible aspect-oriented API. Second, similarly to Jalangi, Ichnaea only supports ECMAScript 5.1.

Dynamic Symbolic Execution

Another prominent application of shadow execution is dynamic symbolic execution which attempts to provide inputs to a program that will lead it to a specific execution path by labeling run-time values with symbols. It is often used to generate test inputs, an approach known as concolic testing [13, 14]. Multiple dynamic symbolic execution frameworks have been proposed for JavaScript [15, 16, 17]. Similar to dynamic taint analysis, these approaches often rely on a modified runtime, whereas we explored source code instrumentation for applicability reasons. The only symbolic execution framework based on source code instrumentation that we are aware of is Kudzu [15], which relies on Jalangi instrumentation and suffers from its limitations.

Value Virtualization There has been some work on virtualizing values in JavaScript which could provide the basis for shadow execution [18, 19, 20, 21]. However, these approaches require executing JavaScript code in a virtual machine, which may limit their applicability and explain why they have not been adopted in practice. Actually, ECMAScript provides its own standard virtualization API called Proxy [3]. Unfortunately, this API focuses on object values and is cannot virtualize primitive values. Despite shown interest 25 , there is little chance that the Proxy API will be extended to primitive values due to performance implications.

Low-Level Shadow Execution

There is also an interesting body of work on performing shadow execution on the lower-level representation of programs. For instance, Valgrind [22] is a popular framework for instrumenting binaries for the purpose of dynamic analysis and is fully capable of carrying out shadow execution. However, because JavaScript is primarily interpreted, and although it is sometimes JIT-compiled, it is unclear how this approach could be applied to a wide range of rapidly evolving runtimes.

Conclusion

We introduced aran, an approach for implementing heavyweight dynamic program analyses. Our method is broadly applicable, relying exclusively on source code instrumentation. However, further research is needed to explore deployment infrastructures that do not compromise this applicability. Our approach is also expressive, featuring an aspect-oriented API that facilitates shadow execution of complex JavaScript programs with just 31 entry points. Furthermore, it maintains transparency by preserving the semantics of the analyzed program, achieving a 99.7% success rate on Test262. Future work should also examine whether the performance overhead remains acceptable in real-world applications.