Try-Mopsa: In-Browser Static Analysis

• Try-Mopsa is a browser-based static analysis platform compiled from Mopsa, offering support for intervals, octagons, and convex polyhedra in client-side applications.
• It employs js_of_ocaml to cross-compile OCaml modules into JavaScript, using browser APIs and Web Workers to replace native system calls.
• Designed for educational use and lightweight industrial tasks, Try-Mopsa retains Mopsa’s fixpoint engine and relational analysis while operating within strict performance and memory constraints.

Searching arXiv for Try-Mopsa and related Mopsa static analysis papers. Try-Mopsa is a scaled-down version of the Mopsa static analysis platform, compiled into JavaScript to run purely as a client-side application in web browsers. It is designed as a zero-install environment for static analysis, with a responsive interface that works on both desktop and mobile devices, and it preserves all the core components of Mopsa, including support for relational numerical domains. In particular, it brings intervals, octagons, and convex polyhedra into an in-browser setting intended for onboarding and teaching, while retaining Mopsa’s generic fixpoint engine and transfer functions (Monat, 16 Sep 2025).

1. Provenance and scope

Try-Mopsa is derived from Mopsa, described as an OCaml-based, interprocedural, parametric static analyzer. Its starting point is Mopsa’s codebase, about 30 KLOC in OCaml, which already separates front ends for C, Python, and Java; a memory and pointer abstraction layer; numeric domains; a fixpoint iterator and widening infrastructure; and reporting and warning emission modules.

This inheritance is central to the system’s scope. Try-Mopsa is not a reimplementation of selected analyses in a browser-oriented language; it is Mopsa cross-compiled into plain JavaScript. The retained components are the same ones that support the native build, which is why the browser version can expose the same family of relational numerical domains and the same transfer functions for arithmetic, tests, and pointer operations. A plausible implication is that Try-Mopsa is best understood as a deployment adaptation of Mopsa rather than as a separate analyzer.

Component	Role in Mopsa	Presence in Try-Mopsa
Front ends	C, Python, Java	Preserved
Abstraction layer	Memory and pointer abstraction layer	Preserved
Numeric domains	Intervals, octagons, polyhedra	Preserved
Iteration engine	Fixpoint iterator and widening infrastructure	Preserved
Reporting	Reporting and warning emission modules	Preserved

2. Browser-oriented architecture

The implementation strategy is based on cross-compilation through js_of_ocaml, which turns all of Mopsa’s OCaml modules into a single pure-JavaScript bundle, with no WebAssembly. The resulting application has zero server-side components and runs entirely in the browser.

The browser adaptation requires several substitutions for native facilities. Custom stubs replace Unix file-system calls with browser APIs, using LocalStorage or IndexedDB for persisting cached results and fetch() for loading user-supplied code or libraries. Dependency management is handled by dune + opam, with a special "js" build profile that pins versions of all OCaml libraries to js_of_ocaml-compatible releases.

Try-Mopsa also introduces new modules specific to the web setting. A thin HTML/JS glue layer exposes an API to invoke Mopsa’s analysis engine on an in-browser text buffer and provides callbacks for sending warnings and intermediate invariants back to the UI. The user interface itself is a minimal web framework based on vanilla JS and CSS, without React or Angular, and embeds CodeMirror for source editing while hosting domain-choice controls, analysis parameters, and results panes. Optional worker threads via Web Workers are used to keep the UI responsive during heavy analysis.

These design decisions collectively realize the stated goal of a pure client-side analyzer. The absence of WebAssembly, the reliance on browser storage APIs, and the optional use of Web Workers delimit the technical identity of the platform as a JavaScript deployment of an OCaml analyzer rather than a server-backed web service.

3. Relational numerical domains

Try-Mopsa supports exactly the same relational domains as Mopsa’s native build: intervals, octagons, and convex polyhedra. The paper gives formal definitions for octagons and polyhedra, which are the most distinctive domains in the system (Monat, 16 Sep 2025).

For the octagon domain, an octagon abstracts sets of program states over variables $x_1,\dots,x_n$ by constraints of the form $x_i - x_j \le c$ and $x_i + x_j \le c$. It is represented as a weighted difference bound matrix $D \in (\mathbb{Z} \cup \{+\infty\})^{2n\times 2n}$. Join is performed pointwise:

$$(D^1 \sqcup D^2)[k,\ell] = \min(D^1[k,\ell], D^2[k,\ell]).$$

Meet is the matrix-wise max. Widening is the usual increasing hull:

$$(D^1 \nabla D^2)[k,\ell] = \begin{cases} D^1[k,\ell] & \text{if } D^2[k,\ell] \le D^1[k,\ell],\ +\infty & \text{otherwise.} \end{cases}$$

Projection onto a subset of variables is existential elimination via graph-shortest-path extraction from the DBM.

For the polyhedra domain, a convex polyhedron over $(x_1,\dots,x_n)$ is defined by a finite set of linear inequalities $A \cdot x \le b$. Try-Mopsa imports Mopsa’s wrapper over the Apron library’s polyhedra functor. Join is the convex hull, computed by adding constraints from each operand and then minimizing redundancies. Meet is simply the union of constraint sets. Widening uses the standard constraint-dropping policy: given $P$ and $Q$, keep constraints of $x_i - x_j \le c$0 that are implied by $x_i - x_j \le c$1 and drop the others.

Transfer functions for arithmetic such as x := y+z, tests such as if x-y ≤ c, and pointer operations are exactly Mopsa’s, so Try-Mopsa inherits their soundness guarantees. This preservation of transfer semantics is what allows the browser version to serve not only as an interface layer but also as a faithful vehicle for relational abstract interpretation.

4. Interface and execution workflow

The front end is a single-page web app built from HTML, CSS, and vanilla JS. On desktop, the interface is split into a left pane containing a CodeMirror editor with syntax highlighting for C, Python, and Java, and a right pane containing tabs for analysis configuration, results summary, and invariant viewing. The analysis configuration tab allows selection of front end, choice of domain, and widening delays. The results summary presents warnings with file and line links. The invariant viewer displays per-program-point relational constraints.

On mobile devices, the layout becomes a full-screen editor by default, with collapsible menus for configuration and output and touch-friendly buttons to start or stop analysis. The interface is therefore explicitly optimized for both desktop and mobile interaction.

The key workflow is linear and tool-oriented:

1. Paste or type source code into the editor.
2. Choose “Octagon” or “Polyhedron” or “Interval” from a drop-down.
3. Optionally adjust iteration limits or widening thresholds.
4. Hit “Run”; analysis runs in a Web Worker, and the main thread stays responsive.
5. As soon as a fixpoint is reached at each program point, partial invariants stream back and highlight the corresponding lines.
6. Clicking a warning navigates to the offending line, and the invariant viewer shows the relational constraints active at that point.

Two usability details are particularly significant. First, the UI avoids file uploads: everything lives in memory or IndexedDB so that users can bookmark their session. Second, the UI explicitly highlights each abstract step—join, widen, and test—so that tool behavior can be correlated with textbook rules. This suggests an interface design shaped as much by pedagogy as by analysis functionality.

5. Performance profile and operational limits

The benchmark regime described for Try-Mopsa covers small C kernels and Python snippets in the 200–500 LOC range. On a modern laptop running Chrome 120, Try-Mopsa runs roughly 2×–3× slower than native Mopsa on the same hardware. Two examples are given. For a 300 LOC C program with octagon analysis, Mopsa native takes 1.2 s, whereas Try-Mopsa in Chrome takes 2.8 s. For a 200 LOC Python example with polyhedra, Mopsa native takes 0.9 s, whereas Try-Mopsa in Firefox takes 2.1 s (Monat, 16 Sep 2025).

The paper also reports that domain operations are fast enough that even 200-line examples finish in under 2 s on a mobile device. Despite the overhead of the JavaScript deployment, the system is described as remaining interactive for “pocket-sized” analyses.

The main trade-offs in the JS build are explicit. There is no native GMP bignum library, so integer overflows are approximated by 53-bit floats. There is memory overhead from JavaScript’s garbage collector and DBM implementation. There is also no true parallelism, since the system uses at most one Web Worker per analysis. In consequence, Try-Mopsa is deliberately limited to 1 KLOC per run.

These constraints define a clear operational envelope. The browser build preserves analysis structure and interactivity, but it does not aim at parity with native execution for larger workloads. A plausible implication is that the browser form factor is intended for bounded experiments, demonstrations, and compact verification tasks rather than heavy batch analysis.

6. Teaching role and nomenclatural disambiguation

One of the main stated goals of Try-Mopsa is teaching introductory static analysis courses without any installation. The paper lists several classroom uses: live demos in which instructors show how changing the abstraction from intervals to octagons refines invariants; interactive tutorials such as proving array bounds safety in a simple loop with intervals, then switching to octagons to recover relational information, and visualizing the DBM matrix for a triangular loop invariant; and student assignments in which each student submits a URL with code and settings encoded in the fragment identifier, enabling instant replays.

Because everything runs in the browser, there is no barrier of setting up OSS libraries or dealing with version mismatches. The system is therefore positioned as a convenient onboarding platform as well as a teaching aid. The summary further states that it can be used both for light-weight industrial analyses up to approximately 1 KLOC and as an in-browser teaching aid for courses on abstract interpretation and static analysis.

The name “Mopsa” is not unique across the literature and can invite confusion. In one unrelated usage, “Mopsa” refers to the monitored-session-erlang framework, an OTP application and library for monitoring Erlang/OTP gen_server applications against multiparty session types (Fowler, 2016). In another unrelated usage, “MOPSA” denotes “Mixture of Prompt-Experts Based Speaker Adaptation for Elderly Speech Recognition,” a Whisper-based speaker adaptation method (Deng et al., 30 May 2025). Try-Mopsa belongs to neither of these lines; it is specifically the browser-deployed form of the Mopsa static analysis platform.