Dear readers,

All future technical posts about our technologies, including Cheerp, CheerpJ, CheerpX, and WebVM will, from now on, be only published on our own blog https://leaningtech.com/news/?q=technicalblog.

The purpose of this short post is to make sure members of the Medium community are aware that we have continued moving the state of the art of compilers and virtual machines for the Web forward.

Over the last few years, our technical write-ups have received many thousands of visits here on Medium. That has made us proud and kept us motivated to publish high-quality technical content which, in some cases, has become a reference of sorts for the whole field.

Around one year ago, we made the decision to prioritize our own blog and domain, as the primary source for all our posts. Although Medium is somewhat helpful in making content more visible, after looking at the statistics, we concluded that maintaining a Medium mirror of our content is not worth the effort.

To celebrate the impact that Medium had on us, let me share a small list. Here are the three most-read articles that we published:

• WebVM: server-less x86 virtual machines in the browser: Where we announced the launch of https://webvm.io, a virtual Linux environment running fully client-side in the browser. This was our most impactful post ever, which is not surprising considering the opportunities that this technology opens.
• Preserving Flash content with WebAssembly done right: Another significant milestone for Leaning Technologies: the first announcement for our plans of solving the problem of Flash content preservation by using our x86-to-WebAssembly virtual machine (CheerpX)
• A JavaScript optimizing compiler: An example of our more research-oriented results. It’s interesting that a few other people have re-invented the same ideas in the meantime :-)

To avoid missing any of our future posts, make sure to follow us on Twitter and join our Discord server.

Leaning Technologies’ developers, including myself, are always available to answer any questions you might have about our tech and products. See you there!

Sunsetting our Developer's Blog on Medium was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

WebVM is a virtual Linux environment running fully client-side in the browser.

It is based on CheerpX: our WebAssembly powered x86 virtualization technology. Thanks to a powerful JIT recompilation engine, and an ext2 block-based filesystem, it makes it possible to run large scale use cases: GCC / Clang / Python / Node.js / Ruby and many other things are supported out-of-the-box.

But something important was missing: networking.

Networking is the most requested feature of WebVM, and for good reasons: without it, you can only input and output data via the terminal, and you are limited to using what we included in the OS image.

The main difficulty in adding this feature is that the browser does not expose access to lower-level protocols such as UDP and TCP. You can only do HTTP(S), and even then, you are severely limited by CORS policies.

What about WebSockets then? A WebSocket connection starts with an HTTP connection with an “Upgrade” header. Then, if the upgrade is accepted, the WebSocket protocol takes over. WebSocket packets also have their own header. So they can’t be used transparently to connect to regular TCP sockets.

In order to connect to arbitrary sockets, we need a proxy server to perform the protocol upgrade and unwrap the WebSocket packets before sending them to the destination (and do the opposite in the other direction).

Hosting this proxy server spawns a new set of problems:

• We need to pay for and maintain a piece of server-side infrastructure, which needs to scale with the number of users.
• Since our server performs the network requests on behalf of the users, we would become legally responsible for the traffic. The service could be abused by malicious actors.

To solve the second issue, we would need to require users to authenticate, keep track of their network usage, and effectively become a VPN provider.

What if we could offload this “VPN provider” business to someone more qualified, then?

If we could find a VPN service that can be used directly from the browser, we could even eliminate the first issue, and avoid the need to host any server infrastructure ourselves.

Meet Tailscale

Tailscale is a VPN service based on the WireGuard protocol. It includes a control plane that manages the WireGuard keys of all the machines in the network and takes care of authenticating users.

Since it’s built on top of WireGuard, and WireGuard uses UDP for communication, you would think that we are back to square one.

One of the features of Tailscale, though, is the ability to let machines connect with each other directly in a mesh network. It achieves this by providing STUN servers for NAT traversal.

Sometimes even the STUN server can’t punch through the NAT, so as a fallback mechanism, Tailscale provides DERP servers.

A DERP (Detoured Encrypted Routing Protocol) server is used to relay traffic when two peers cannot connect directly. Since it’s designed to circumvent even the most annoying firewalls, it communicates using regular HTTPS and Websockets.

That’s exactly what we need!

Now we just need to reimplement the Tailscale control plane protocol, the DERP protocol, and the WireGuard protocol in the browser, and we are set.

Just kidding! Luckily for us, the official Tailscale client (written in Go) compiles to Wasm.

By slightly modifying their browser ssh client (tsconnect), and implementing a custom Tun device, we successfully communicated with a Tailscale network by just sending/receiving IP packets on a JavaScript MessageChannel!

About Go and Wasm

I was pleasantly surprised by how easy it is to compile Go code to Wasm.

You just need to set the environmental variables GOOS=js GOARCH=wasm, and ship $(go env GOROOT)/misc/wasm/wasm_exec.js alongside the wasm module.

Of course, your dependencies need to support the wasm target (and in my case, the folks at Tailscale did all the work).

One downside is the size of the compiled wasm module: 16MB!

Wasm-opt didn’t help much either: it shaved just 1MB. For comparison, the whole CheerpX VM fits under 6MB.

For this reason, the networking code is lazily loaded only if you attempt to log in to Tailscale.

TCP/IP Stack

With surprisingly little work, we can now exchange IP packets from a Browser. Unfortunately, most applications don’t send raw IP packets, but use TCP or UDP to communicate.

We could build a TCP/IP stack from scratch, but hopefully, we can find an existing one.

Lwip (written in C) seems to be a common choice in the embedded world. It was pretty easy to compile it to Wasm with Cheerp, and to add a “driver” for our MessageChannel network interface.

The only missing part is to implement a bunch of network-related syscalls in CheerpX using lwip, and we are good to go.

Demos

Enough with the theory, what can we do with this thing?

SSH

The most straightforward use of a network-enabled WebVM is to use it as an ssh client:

You can access other machines in your Tailscale network (and beyond, if you have an exit node) from any browser, in a privacy-preserving way. Your keystrokes are not only encrypted, but they don’t touch our servers at all.

You can also use ssh to easily move files in and out of WebVM. This increases the scope of what you can practically do in WebVM, since you can now import code/data to execute and export the result of your work.

Full stack web development

A more ambitious goal is to use WebVM as a full-stack development platform.

Admittedly, we are not really there yet, but networking is an important step towards that goal.

In the next demo gifs, you can see me:

• downloading a Python git repository from github.com

• installing dependencies with pip

• running a Flask web application that includes a Sqlite database for persistent storage, and access it from a second browser tab

• access it from another WebVM tab, with lynx

• edit the application, commit to git, and push back to github

It is certainly not fast to install the pip dependencies (some setup scripts are compiling native code there!), but thanks to our IndexedDB-backed filesystem, you only need to do that once.

And there are of course many more limitations. For example, npm is not working yet, nor is apt. But none of these issues is particularly complex to solve, and our syscall emulation layer is constantly improving (thanks also to the expanded set of applications that we can run with network support).

Try it yourself

If you want to give it a try yourself, here are the steps to enable network access in WebVM:

• Go to webvm.io and click “Tailscale Login” in the top right.
• Depending on your network speed, you may need to wait a few moments for the Tailscale Wasm module to be downloaded.
• Log in with your Tailscale credentials.
• If you want to access the public internet, you need an Exit Node. See here for how to set one up. If you just want to access a machine in your Tailscale Network, you don’t need it.
• Go back to the WebVM tab. You will see your IP address in the top right.
• Start firing network requests!

Given the short-lived nature of WebVM, we log into Tailscale as an Ephemeral Node. This means that the node will disappear from your Tailscale Network after a period of inactivity. It also means that when you reload the tab, you need to log in again. It should be faster the second time.

What’s next?

We are very excited about the possibilities that network support unlocks for WebVM.

And while we have ideas on what to do next (hint: X11), we are also curious to hear about what you would like to use WebVM for.

You can get in touch by email or on Twitter, or have a chat on our Discord channel.

If you try something, and it doesn’t work, feel free to open an issue on GitHub.

Discussion on Reddit: https://www.reddit.com/r/programming/comments/xx3r83/webvm_linux_virtualization_in_webassembly_with/

Discussion on Hacker News: https://news.ycombinator.com/item?id=33116245

WebVM: Linux virtual machine in the browser with full networking via Tailscale was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

A recurrent need for anybody practicing programming is running (and sharing) small snippets of code to quickly test an idea or ask for feedback. These kinds of Web applications are generally called ‘fiddles’, and there are plenty of them out there. The common use cases for fiddles are in education, but anyone can find themselves needing to use one to avoid having to set up a full native execution environment.

Most of these types of fiddles work by sending user code to a virtual machine that runs in the cloud. The program is then executed remotely and the result is sent back. Using a modern cloud environment has lots of advantages, in particular scalability and relatively low costs, but it does leave the developer open to a few issues:

• Privacy: There are two parties who need to be concerned about privacy: the user and the service provider. For users the main concern is what is done with their data. Will it be stored on the servers or possibly left accessible in logs. The provider on the other hand will need to know what they can and cannot do with user data, and if they’ll need to inform or ask the user for consent. This is particularly true in cases where the data isn’t just code snippets.
• Security: Allowing execution of arbitrary, user-written code can leave service providers vulnerable to abuse. It’s possible to harness the computational power meant for running the application for malicious purposes, like DDoS attacks or crypto mining. These are real problems for any platform that allows anonymous execution. This problem is extremely difficult to solve, since users are fundamentally unpredictable, whether we are speaking of the code they produce or their intentions with the application. Often primitive solutions such as timeouts, quotas and banning packages or libraries are used as a workaround.
• Cost: As low as the computing costs might be, somebody will still need to fork over the payment for those servers. The scalable nature of the cloud implies that, as the project gains more success, the costs will also scale. This may become an issue for single developers, Free and open-source software projects, or non-profit organizations.

An ideal alternative to cloud-based execution would be to take an existing language implementation and port it to the browser environment. The effort required will of course depend on the language ported and complexity of implementation, but it’s reasonable to expect it will be significant. On top of the effort put into the porting process, it will be easy to introduce brand new issues, and none of the work will automatically translate to supporting a new language.

Several years ago we released JavaFiddle, a client-side execution environment, that was able to address most of the problems mentioned above. It’s based on CheerpJ, our solution to compile and execute Java bytecode on the browser in WebAssembly and JavaScript. Because of this, JavaFiddle is able to run Java applications sandboxed in the browser. This solution worked very well and the application gained quite some use.

Now we’re releasing PythonFiddle, a similar environment, that allows the user to play around with python. This time, however, it’s based on CheerpX, our WebAssembly based x86 virtual machine, that is able to run any program that is compiled to x86 assembly. This solution will allow us to bring a similar solution to many different language implementations, and much more.

What is CheerpX?

CheerpX is a virtual machine that is able to run x86 executable programs in the browser. It’s based on WebAssembly, a new bytecode for the browser intended to be used as a compilation target for programming languages. CheerpX has a two tiered execution engine composed of an interpreter and a just-in-time compiler. The interpreter runs rarely executed assembly instructions and generates metadata for the JIT, which in turn can generate efficient Wasm modules for frequently run code.

Working directly with machine code has several advantages for CheerpX:

• Robustness: most programs will just work without issues. Compiling from source to Wasm is technically possible, but would lead to us needing to support many more individual use cases, and a lot of software wouldn’t be viable for execution.
• Versatility: There are also cases where there is no source code available for compilation, like Flash. This will not be an issue for CheerpX either.
• Accuracy: Applications will run identically to the way they work in native.

As an added bonus, CheerpX provides extensive support for file manipulation using a virtualized file system based on Ext2. The disk blocks are downloaded on demand from our CDN to minimize network usage. The blocks are themselves cached using IndexedDB to avoid redundant downloads on later visits. As the file system and all the changes made in it are stored in the browser’s local IndexedDB, none of this data will appear on our servers either, which makes this solution both extremely scalable and privacy preserving.

What is PythonFiddle?

PythonFiddle is composed of a few components:

• CheerpX: runs the python interpreter with the user-written code snippet in real time in the browser.
• Debian buster disk image: gives access to a complete file system.
• Xterm.js: provides a full terminal experience, including formatting and support for curses-based apps.

Being able to leverage the features mentioned above gives us a slew of advantages on this project:

• Native-like execution: with access to a proper file system and multiprocessing capabilities, the users will be able to take advantage of most functionalities of python without issues. This includes read/write access to a full Debian file system image, multithreading, subprocess and most python libraries.
• Privacy-preserving code sharing: To share code, it is compressed and encoded as a hash of the url using lz-string, and then decoded on the receiving side directly from the url. This way users can share their code without it having to pass through our servers. You can test it by using this link.
• Robust against abuse: since code execution occurs entirely sandboxed to client-side and nothing will be sent to our servers, we are safe from any form of undesired usage.
• Scalability without costs: all processing and execution occurs client-side, which means that a minimal amount of our resources will be spent, even if the amount of users grows considerably.

Although we believe PythonFiddle (and the updated JavaFiddle) to be useful in themselves, CheerpX has the potential to be used in much more sophisticated applications. The possibilities are not limited to language implementations either, but any x86 code can run safely client-side. It’s a stable technology already exposed to the public via the many demos we’ve released over the past months. The most recent demo, WebVM, runs a full terminal session in a debian distribution in the browser. This shows just how complex the tasks CheerpX can achieve are.

Integrating CheerpX in web apps isn’t complicated either. The fiddle itself is just a thin layer on top of the CheerpX API. To run any program, you’ll only need to call the `CheerpX.run(…)` API call with the program, and CheerpX will take care of everything.

CheerpX.run(“python3”, [“-c”, “print(’Hello world!’)”], env); 

CheerpX is already incredibly versatile technology, but nevertheless we’re continuously adding more functionality. Currently we’re implementing networking capabilities and support for running graphical applications. This would allow the creation of even more complex demos and applications. The possibilities are endless.

As CheerpX is so adaptable, there are certainly many use cases we have not thought of yet, and therefore we are looking for partners who will bring CheerpX to unexplored markets. If you have a fantastic idea that could be made into a reality using CheerpX, please get in touch:

Email: info@leaningtech.com

Twitter: https://twitter.com/leaningtech

Discord: discord.leaningtech.com

Web: https://leaningtech.com/cheerpx

PythonFiddle: Fully private client-side sample code execution and sharing was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recursion is one of the fundamental primitives of computer science. Many algorithms came to life by simplifying a general problem into recursive sub-problems. From the perspective of code, recursion implies that a function would call itself as part of its logic. Since stack is consumed for each instance of the function, excessive recursion depth will cause what is known as a stack overflow: a problem significant enough to become the namesake of the biggest programming Q&A platform on the planet!

If a recursive call happens to be in tail position (i.e. just before the function returns), this issue can be solved by using tail recursion. In this context, we could assume the caller’s stack frame can be reused before jumping into the callee, turning these calls into tail calls. This is a key concept in CPS (Continuation Passing Style), used by some functional programming languages where functions do not return but instead invoke a routine on their result, using tail calls to avoid exhausting the stack.

WebAssembly is a modern bytecode that can be natively and efficiently run in browsers. It is designed to be a suitable compiler target for most other programming languages, including functional ones. Speed and efficiency being at the core of WebAssembly’s design, it is unsurprising that tail calls were proposed as an extension to the standard.

For a proposal to become a fully approved standard, a few steps are required, including being implemented by two different browser engines. V8, the engine used in Chrome and Edge, added support for WebAssembly tail calls in 2020. It was a step in the right direction, but since then, the state of the proposal has been stagnating.

As Apple’s Webkit already implements proper tail calls in ECMAScript 6, we thought it would be a good target to implement the feature and try to move the status of the proposal forward, eventually towards full standardisation.

This article aims at demystifying WebAssembly tail calls while giving the reader an idea of how we have implemented the feature in WebKit.

Let’s refresh our memory…

There are different ways of representing function arguments at the machine level, these are named “calling conventions”. We will focus on how the call stack is allocated and how arguments are passed in JavaScriptCore, Safari’s JavaScript engine. Similar reasonings can apply to other environments.

The following C code shows a classic example of a tail-recursive solution to compute and print the factorial of a number.

Let’s focus on the first recursive call in factorial.

Two definitions are needed:

• The caller: factorial 0, the first instance of factorial.
• The callee: factorial 1, the first tail-recursive call to factorial.

To understand what happens at the machine level, we need to introduce two players: the frame pointer, which refers to the first byte of the current frame, and the stack pointer, which represents the top of the stack. Between them lies the data of our function. In JavaScriptCore, this would include stack values, virtual registers, local variables and the call frame header. The latter contains the state required to “return”, including the previous frame pointer and the caller’s instruction pointer.

Arguments are used to carry information from the caller to the callee. There are two ways of passing them: in registers or on the stack. The register approach is ideal since operations on them are much cheaper. This cannot be always done though, since we might have more values than registers available, in which case they will be “spilled” onto the stack. Managing stack space is one of the critical aspects of implementing tail calls.

When factorial 0 calls factorial 1, we will first go through the callee’s prologue:

push $arg0          \
push $arg...        |   caller’s frame (factorial 0)
push $argN          |
call $factorial     /
    push %rbp        \
    mov %rsp, %rbp    |  callee’s frame (factorial 1)

Note: this is a tracing representation of pseudo assembly instructions in x86 AT&T syntax.

This grows the stack by the size of a register, and stores the previous frame pointer (%rbp). The return address is already written on the stack automatically by the CPU.

After that, anything can happen in the function as long as we reach the epilogue, symmetrically opposite:

push $arg0           \
push $arg...         |   caller’s frame (factorial 0)
push $argN           |
call $factorial      /
    push %rbp         \
    mov %rsp, %rbp    |
    ...               |    callee’s frame (factorial 1)
    mov %rbp, %rsp    |
    pop %rbp          |
    ret               /

The first instruction resets the stack pointer to the address of the previous frame. The pop instruction corresponds to the push in the prologue and it will restore the stack frame as it was before entering the callee, allowing the caller to access its local data again. ret will redirect the control flow using the address stored at the top of stack by the last call instruction, allowing us to go back to the caller’s frame.

If we call factorial with 1 as an argument, factorial 1 ends the recursion and we go through two epilogues:

push $arg0    \
push $arg...  |   caller’s frame (factorial 0)
push $argN    |
call fib      /
    push %rbp         \
    mov %rsp, %rbp    |
    ...               |    callee’s frame (factorial 1)
    mov %rbp, %rsp    |
    pop %rbp          |
    ret               /
mov %rbp, %rsp \
pop %rbp       |   caller’s frame (factorial 0)
ret            /

This is wasteful and can be optimized. Here lies the concept of tail call elimination, through which we consider the callee as an extension of the caller.

How it can be done in WebAssembly: return_call

The following shows the WebAssembly equivalent of our factorial example, with tail calls enabled.

In JavaScriptCore, WebAssembly would be first parsed and validated, then native code would be generated to delegate execution to the machine.

Since tail calls are a variant of regular calls, we could reuse most of the existing infrastructure in the engine. A new routine was added to prepare the frame before entering the callee’s prologue. These modifications do not require runtime gathered information, thanks to WebAssembly’s static typing.

Let’s examine the stack at factorial 1 call site: the first time factorial 0 recursively calls itself. For the sake of simplicity, we will abstract the call chain print_factorial → factorial 0 → factorial 1 to A → B → C.

B contains the return_call instruction, so it must be responsible for adapting the stack. We don’t need its frame after it performs a tail call.

We will thus merge B and A, before jumping into C.

Notice what changed in B’s data. We made sure C will return to A, by preserving the value that was pushed into the stack when A first called B (Fig. 1). Later on, we will make sure to start C with a jmp instruction instead of call to prevent the CPU from overwriting the saved return address.

While C is an extension of B, it still depends on information that B is responsible for. That is why we reused A’s stack space to store C’s arguments (Fig. 2). To carry this out, we needed to know how much stack slots B and C required. We could get that information by reasoning on the functions’ signatures during static analysis.

Fortunately, we didn’t have to worry about variable arguments, since they are not part of WebAssembly’s design. We could then compute a new stack offset, and copy what is needed from B to A.

Interestingly, from the perspective of A, we could say that A and B have been merged. At this point, we are ready to jump into C.

We will now compare a deeply recursive call to factorial, both with and without using return_call.

It becomes apparent that with return_call, we only use one frame for factorial and all potential recursions of it.

Arguments vs. Return values

WebAssembly also supports multiple return values. This implies that the stack used by arguments equally stores the callee’s return values. This plays well with tail calls, since we can assume that A has enough space for B’s return values (Fig. 4). The tail calls specification also ensures that B can only tail call a function that returns the same number of values. However, this raises a concern regarding their offsets on the stack

The previous convention implemented by JavaScriptCore would prepare the frame as in Fig. 4, placing the return values closer to the stack pointer. With tail calls, we introduce the possibility of the frame being reused, which changes the size of the stack in case of a chain of calls with a varying number of arguments. In such a situation, A won’t be able to find the return values at the expected offsets (Fig. 5).

This is due to the fact that offsets for stack values are computed statically when parsing code for a function. As a solution, we changed the convention to encode return values at the opposite side of the stack, closer to the caller’s frame pointer.

When A restores the stack pointer as if it had called B, it is able to find the return values where expected.

We therefore have demonstrated a viable implementation of tail calls in WebAssembly. While being rather straightforward conceptually, the feature has to find its place in a complex codebase with many moving parts involving the stack, for example: exception handling. The implementation is still going through reviews at the time of writing and I invite you to consult the pull request for a more technical follow-up.

The next steps

We hope to see WebAssembly tail calls land in JavaScriptCore soon. This would effectively push the proposal to the next phase, paving the way for a full standardisation.

Our original motivation for making tail calls available in WebKit / Safari, and eventually in the WebAssembly standard, is improving the performance of CheerpX: our virtual machine designed to run x86 binaries in the browser. As stated in our previous article, enabling tail calls in WebAssembly would allow us to reduce the JIT-ted code overhead in the case of indirect jumps, which are commonly used to implement library calls.

Broadly speaking, the standardisation will help modern browsers in supporting modern programming language features such as C++20 coroutines, which LLVM represents as a call with the ‘musttail’ marker. This cannot be appropriately represented in WebAssembly without tail calls.

Through this contribution, we aim to move WebAssembly tail calls from an experimental state to a fully standardized feature, making it available for everyone on all major browsers.

If you are interested in the ever-evolving world of in-browser virtualization, we invite you to follow us on Twitter and Medium.

Fantastic tail calls, and how to implement them. was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

CheerpJ is a solution to run unmodified Java applications on the browser, in WebAssembly and JavaScript.

It is based on two components: a full Java runtime environment in WebAssembly and JavaScript, and an ahead-of-time Java bytecode to JavaScript compiler. By combining these two elements, CheerpJ provides an environment to run any type of Java application (stand-alone, Java Applet, Java libraries) as a pure HTML5 Web application.

CheerpJ, originally released around 5 years ago, is trusted by many large organizations to:

1. Preserve access to critical internal Java clients (Java applets and stand-alone applications) without relying on legacy browsers, and without a client-side Java installation;
2. Convert existing Java products into HTML5, and provide them to external users as a browser-based experience;
3. Integrate complex Java components as part of web applications, or develop new web-based interfaces to Java-based products.

CheerpJ 2.3 is the only solution on the market to migrate real-world large-scale Java applications to modern HTML5 with pixel perfect accuracy.

CheerpJ at a glance

CheerpJ can be used to run Java bytecode on the browser as WebAssembly/JavaScript.

It is intended to work as a pure-HTML5 replacement to the JVM, and allow any type of unmodified Java client to run on the browser.

Being compatible with 100% of the Java 8 language (including reflection and all dynamic features), as well as with the full Java 8 runtime, it can run any application including Swing clients, AWT clients, and any complex frameworks, including Oracle Forms.

Thanks to Java-JavaScript bidirectional interoperability, CheerpJ can also be used to integrate Java libraries as part of web applications, or to rewrite UIs to legacy Java clients.

CheerpJ provides several browser-based system functions, including virtualized file systems, I/O, networking and audio.

Since release 2.2 (release notes here), there have been improvements in how files are read and written in our custom file system, class generation now allows for non-ASCII fields to be present and improvements in how network connections are handled have been made. The full Change log for version 2.3 of CheerpJ is available here.

Getting started

CheerpJ 2.3 is available for Windows, macOS and Linux. You can download it, integrate it and test it with no restrictions.

You can head to our Documentation for examples and tutorials.

How to upgrade to CheerpJ 2.3

To try out or update to CheerpJ 2.3, simply download the compiler here , and rebuild your project with the new compiler.

If using the CheerpJ cloud runtime, make sure to change your CheerpJ runtime header to

<script src=”https://cjrtnc.leaningtech.com/2.3/loader.js"></script>

The old 2.2 version will keep working, but the only way to gain the benefits of this new release is to change the runtime endpoint and regenerate the jar.js files.

Please notice that using the new runtime with a jar.js generated with the 2.2 compiler is unsupported and might lead to unexpected behaviors.

Download and try CheerpJ

If you have never tried our compiler before it’s really easy!

Just only have to use our compiler that you can find here and update your HTML page hosting the applet or create a simple HTML for it.

You can follow this link to our wiki and follow the Getting Started for detailed instructions.

You can also try CheerpJ online using our Java Fiddle.

Future releases

We have exciting news for the next release, more of which will be shared in the coming months!

For CheerpJ 3.0 we are planning a complete redesign of the compiler based on the lessons we learned from working on CheerpX and WebVM.

The new architecture, that we are currently designing, will bring improvements to startup time, download size and compatibility with sophisticated Java frameworks.

CheerpJ 3.0 will, one more time, redefine what running Java in the browser means.

Get in touch!

To report any issues, please use our issue tracker. For any question or comment, you can find us on the CheerpJ Gitter channel.

Feel free to get in touch also on:

Email: info@leaningtech.com

Twitter: https://twitter.com/leaningtech

Github: https://github.com/leaningtech/cheerpj-meta/

Web: https://leaningtech.com/cheerpj

Thank you!

CheerpJ 2.3 released was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I will explain the ideas behind it, the engineering challenges, and the results of this work.

LLVM basics

Some basic understanding of LLVM internals will be helpful, if you are already familiar with such concepts feel free to skip ahead.

The basic process of compiling is:

• a program is first represented as a collection of source files
• code is transformed by the front end into an equivalent IR (=Intermediate Representation)
• optimization passes transform the original IR into a more compact and performant IR
• the optimized IR is converted into an executable for a given target

The advantage of this architecture is that different concerns are separated in different components:

Language specific semantics and checks are only needed in the first step (source -> IR).
Target specific information is only needed in the last step (IR -> executable)

We will concentrate now on the “middle-end”, where IR to IR transformations are performed.

One of the core features of the LLVM framework is the vast amount of sophisticated optimizations which are done in this stage.
The Intermediate Representation of functions will be a graph (representing the control flow) connecting groups of statements that are executed sequentially (Basic Blocks).

The problem: reducing code size

I work on a C++ to WebAssembly & JavaScript compiler, Cheerp.

There is quite some magic involved in the various details, but at a high level this is just another compiler. The source code is parsed, optimized, and code-generated. The main visible difference is that instead of a native executable, Cheerp generates a .js and a .wasm file.

The code is then embedded, either directly or as dependency, in a HTML page and it’s loaded on first use before being executed. Load time will directly impact users and reducing the code size is a more critical concern compared to your typical native target.

An important part of the development of Cheerp is working on improving the generated code size, and so there was I, tasked with staring at LLVM’s IR and looking for new optimization possibilities.

Getting a baseline

I knew there had to be code that was never actually executed since other optimizations I touched in the past started from this assumption.

You might have heard of dead-code elimination, an LLVM optimization pass that removes code proven as unreachable. I was actually interested in less-obvious situations. In particular blocks that are reachable on the control flow graph, but not when consider wider execution invariants.

If there was a way to prove that certain blocks are never executed, they could be then removed and this change would not be observable.

To get started, I first played a bit with the generated code, adding some assert(false) in the suspicious parts. I executed the code and the assertion seemed to never be triggered.

Then I took a more systematic approach: instrumenting the generated code, running it on a diverse set of inputs, and collecting statistics about never executed blocks. I then removed such code completely and compared the output size to the original one. The potential size improvement seemed significant. I knew I was onto something.

There were obviously false positives, but I identified a significant test case to start with: printf.

Printf

printf is a standard C library function that takes a format string and a variable number of other arguments.

int printf(const char* format, ...);

printf(“Here a somewhat random number: %i\n”, rand());

printf is complex enough to have been shown to be Turing complete (see IOCCC or the paper).

The format string could come from anywhere or be generated at runtime. But in many cases it will be just a string literal, known at compile time.

Can we use information on the call-sites and the corresponding format strings to prove that some code paths, for example formatting for floating point numbers, are actually never taken?

And can we do it in a way that is fully agnostic of the actual implementation of printf?

And can we generalize the approach so that it works on any function?

It turns out the answer to all 3 questions is “Yes”.

Partial Executer: game plan

runPartialExecuter(Function& Fn)
{
    Set<BasicBlock> visited;
    for each CallSite CS of Fn:
        partialExecute(CS, Fn, visited)

    for each BasicBlock BB of Fn:
        if visited.count(BB) == 0:
            BB.replaceWith(unreachable)
}

The logic that we have to perform is: keep a set of visited blocks across all functions, iterate all call-sites, and then eventually remove blocks that have never been visited.

Simple enough. The devil is then in the implementation of the partialExecute function, but we can start with a simpler problem and see whether we can make any progress in solving printf.

Step 1: arguments known, no interaction with global state

Say a function doesn’t load or store global data, and all its call sites have known arguments.

Then it’s only a matter of using an interpreter and executing one instruction after the other. Eventually, branches will be interpreted and correctly predicted, so it is trivial to follow the flow of the function.

Fortunately as part of the LLVM framework there is an interpreter for LLVM’s IR, so we can reuse the existing ExecutionEngine / Interpreter infrastructure.

We start by populating the arguments with the known values and registering a callback to inform us about instructions that have been visited, and let the ExecutionEngine do its job.

Another problem we have to solve is a Computer Science classic: “Is this function ever going to terminate?” (the halting problem).
Here we will use a trivial approach, whenever a Basic Block (= sequence of Instructions) is executed more than a fixed amount of times, we stop the interpreter while marking all Basic Blocks in the function as visited.

Step 2: allowing Stores to global state

Say that we store to global memory but we never load (= read) values from it.

Since we will never load, there is no way to observe whether a value has actually been stored or not. So while interpreting we can ignore stores, since they are not observable.

Here we are adding a new insight: at interpreter time we are not actually interested in full execution. A more relaxed partial execution is sufficient.

Consider as an example this code:

void someFunc(int n)
{
    someGlobal = 42;
    if (n == 57)
        //some stuff
}

And we know that for all call sites the argument ’n’ will be different than 57.

Here we could safely transform someFunc to:

void someFunc(int n)
{
     someGlobal = 42;
}

Setting someGlobal to 42 will be observable by the rest of the program, so it has to remain in the function, but we can still process the rest of the function and possibly optimize it.

Step 3: allowing Loads from non-mutable global state

Here things will start getting interesting.

void processString(const char* ptr)
{
    if (*ptr)
        // do something with ptr
    else
        // String it’s empty, fail 
}

Say that the interpreter needs to decide what branch should be executed. Doing so requires loading from the memory pointed by ptr and checking its value.

Can the load be actually performed by the interpreter?

While initializing the ExecutionEngine we will determine (using IR information) that certain ranges in memory are known to be read-only, and while performing Loads we can query whether the loaded pointer is included in those ranges.

Step 4: skipping Instructions

In step 2 we used the fact that Stores are not observable to skip them over, but we can generalize the logic further, since there are many more reasons that could cause an Instruction not to be evaluated by the interpreter, for example:

• some of its operands might not be known (e.g. a function argument that is unknown at interpreter time)
• it’s a load from a memory location we can’t prove read-only
• it’s an instruction that can’t be interpreted (e.g. gettimeofday())

Bailing out and marking any Instruction in the current function as visited is always a valid fallback, but we can do better and try to preserve information further.

We can mark a given Instruction as unknown, and go to the following one. Note that instruction with unknown operands will themselves tagged as unknown.

This logic is sound, given that we are never loading from mutable state, all observable effects an Instruction can have are encoded on its computed value. If we keep track of which values have been computed, we can use the information to decide which Instructions have to be skipped.

With this approach we can robustly deal with any instruction we cannot interpret, as long as it does not impact the control flow.

Handling non-predicted control flow is the next step.

To recap, the visiting algorithm at this point has the following components:

1. a set of visited Basic Blocks
2. a map between Instructions and their computed values (for a given call site)
3. a function to decide what Instructions have to be skipped (informed by the map 2)
4. the Interpreter logic that from an instruction and its operands compute the value

Step 5: Fun with graphs

Here is how printf begins. It performs some allocations, then checks whether some global state has been properly initialized and branches based on that.

In our current model, this is a big show stopper.

Fortunately, it is possible to expand the logic further to non-predicted control flow instructions.

Looking at the control flow graph, it seems like we could just say “skip the first two blocks”, but we would need a formal way to decide where in the CFG we should resume execution.

It’s time for Strongly Connected Components.

The basic algorithm for SCC decomposition works as following:

1. assign each Basic Block to its own component. Edges between blocks becomes edges between components

2. as long as there are cycles in the component graph, merge them in a single (connected!) component

3. the SCC graph will have now no cycles, and each component will represent a group of Basic Blocks.

Absence of cycles means the SCC-graph is now a Direct Acyclic Graph (link), that has the useful property to be topologically sortable.

Intuitively we can treat each Strongly Connected Component as a separate sub-function, and visit them in order.

We will start from the component containing the entry point. We will visit it, collecting the outgoing edges.

While visiting a given component we will iterate over the edges that reach it from outside, determining how many possible entry points there are.

If there are none, the component (and so the blocks it represent) will never be visited, so we can go to the next one.

If there is a single possible starting Basic Block, we will treat it as the entry point of the function, and proceed from there.

In some rare cases, there might be more than one. In such case, we bail out marking every Block in the component as reachable (also including every outgoing edge).

I know we are already deeply in graph territory here, but we have to dig further, stay with me for the very last step.

Step 6: Recursive fun with graphs

Some of you may have noticed a gap in the previous reasoning: how do we treat edges that loop back in what we considered an entry point of a component?

Back-edges will invalidate whatever knowledge we gained. Any way to avoid that?

At the very high level, what we will be doing is making a copy of the (unique) starting block for a given component. All edges from within the component to the starting block will be routed to its copy.

Now the starting block has no incoming edges any more, so we can proceed to interpret it without fears that eventual back-edges will force us to backtrack.

Even better, since there will be no incoming edges from within the component, we can use the SCC algorithm once again to further split the blocks, recursion!!

What we will be doing is basically visiting loops in depth, hoping that they terminate in a given number of iterations. If that happens, great, we can propagate information downstream. Otherwise we backtrack, mark the current component and all its outgoing edges as visited and go to the next Strongly Connected Component.

To guarantee termination, we will use the same approach as step 1: we keep a counter of how many times a given Basic Block is visited, bailing out if greater than a fixed amount. This bounds the total running time of this optimization to linear in the number of Instructions. (waving hands)

Recap

Partial Executer allows the removal of proven unused code, decreasing code size.

To get there, we have used the fact that Functions are mostly independent to partially execute them and prove that some Basic Blocks are never part of any possible execution path.

Removing code has an indirect benefit as it might unlock further optimizations. Compilers are a game of small gains, and any additional piece of information may be leveraged by the following stages.

The End!!

Thanks for following me to here, I will be looking forward to any feedback (@carlo_piovesan).

Partial Executer has been shipped together with the Cheerp 2.7 (rc1) release. Code is available here, issues here, benchmarks and release article here.

I would like to thank all my colleagues at Leaning Technologies for the brainstorming sessions, guidance and reviews that helped put this optimization together.

Kitchen sink for loosely related information that did not fit in the article or have been added afterwards:
- Yuri Iozzelli’s work on PreExecuter had a different angle while using the same components
- WebVM / CheerpX developments by Alessandro Pignotti informed the choices made here

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we are releasing Cheerp 2.7, an unique tool for creating WebAssembly and JavaScript-based libraries from C++ code bases.

UPDATE, 10th March: in depth article on PartialExecuter is out.

Powerful JavaScript-C++ interoperability, support for exceptions and for ES6 modules, and performance and code generation improvements built on top of LLVM’s clang are now available at these links:

GitHub | Issues | Install links | Documentation | Discord server

The whole team at Leaning Technologies is proud to share the progress done in the last year of development, the benchmark’s results, documentation and tutorials.

Cheerp in use

• a Virtual Machine that runs arbitrary x86 exes in-browser ->WebVM
• the Web-based version of an architectural CAD -> home.by.me
• a cartoonish multiplayer game (WebRTC included!) -> TeeWorlds-web

What have these projects in common?

Those are complex Web applications, they all rely heavily on interactions with a multitude of browser APIs and external libraries (interoperability ✔), they all require to be lean and performant (optimizations ✔), and all have central components that are C++-based (compiler ✔). And they are made with Cheerp.

The examples are diverse, but the intuition is the same:

• Browsers are among the most widely available technology, and they act as a standardisation layer allowing both existing tools and new projects to reach new users.

JavaScript engines (Chrome’s V8, Safari’s JavaScriptCore or Firefox’s SpiderMonkey), are an efficient sandbox mechanism that allows code to be executed directly on-device.

Code running in browsers is restricted to be either JavaScript or, since its introduction in 2018, WebAssembly.

How to transform a C/C++ codebase (normally compiled as a native executable) to a WebAssembly or JavaScript-based library encoding the same logic?

Cheerp is based on LLVM’s clang, an industry standard compiler, and the same process that allows C++ code to be compiled to native is followed:

• code is parsed, eventual warnings and errors are emitted, and then a equivalent IR (=Internal Representation) encoding the input program is generated
• the IR is optimised by a series of transformations into more compact & more performant IR
• the optimised IR is finally code-generated as a combination of JavaScript and WebAssembly functions and variables

Once the .js and .wasm files are generated, it’s a matter of serving those 2 static files, embedding them into the relevant HTML pages, building functionality on top of the library’s API, and testing whether all is in order.

Invoking Cheerp again after any change or iteration on your C++ codebase leads to regenerating the files, ready to served instead of the previous versions.

Why Cheerp?

A wide array of other tools exist to help developers create better JavaScript and WebAssembly libraries, but Cheerp is a powerful bridge between two very different models: garbage-collected JavaScript and linear-memory based WebAssembly. And Cheerp’s capabilities unify across the JavaScript / WebAssembly divide, allowing projects developed with Cheerp to be completely encoded in C++.

Why is this fundamental?

• Whole program optimizations and analysis are enabled (improving performances and footprint in way that would be otherwise not reachable)
• Allows all output to be code generated by a single tool, that means simplifying the process and allow for simpler debugging
• The same tool will perform checks in all different components (emitting errors and warnings when things get out of sync). This can significantly improve developers productivity.
• Allows to leverage both C++ and JavaScript ecosystems
• Allows to leverage WebAssembly capabilities as efficient compilation-target
• Allows your libraries to have more powerful interfaces

One example to get more concrete:

typedef bool(JSComparator)(client::Object* a, client::Object* b);

[[cheerp::jsexport]]
void stableSort(client::Array& array, JSComparator compareFunc)
{
    const unsigned int len = array.get_length();
    std::stable_sort(&array[0], &array[0] + len, compareFunc);
}

What is this about?

This port the implementation of std::stableSort to JavaScript.

Example of usage while integrated is:

var someArray = [];
//populate someArray
stableSort(someArray, (a,b) => (a < b));

The input is “regular” C++ with just two additional features:

• client::Array and client::Object classes, forward declared by cheerp-provided libraries
• the [[cheerp::jsexport]] attribute (used to signal that the function should be part of the external interface)

The output is also “regular” JavaScript, ready to be included in whatever project or library.
Here in particular we generated a function taking a JS-callback and modifying an arbitrary Array-like object.

It could have been adding CSS properties or classes, interacting with the DOM when a callback is fired, creating objects of the same class either in C++ code or in JavaScript code, or basically whatever is required in your domain. Cheerp’s flexibility in both using and producing powerful interfaces means less constraints are put on how your program could behave.

The main advantage from using compile-from-C++ components is that the exact same logic is first ported and then executed. This means that non-trivial-to implement algorithms and data structures can easily be ported over.

Performance wise? This is likely to be the fastest user-land implementation available for a non-adaptive stable sort.

Then Array.sort it’s already provided, so that should be the recommended solution, but you will be positively surprised to discover how compilation-from-C++ might be a powerful, efficient and performant solution in your toolbox.

A year of development

As with any code base, also Cheerp undergoes iterations of improvements, fixes, added features and round of optimizations.

There have been many significant contributions since release 2.6, the most visible work from an user perspective has been done on:

Rebase to the upstream branch of LLVM

Cheerp is an open source fork of LLVM’s clang, rebasing allows any upstream improvement to be enjoyed by Cheerp-processed codebases. New C++ features (eg. -std=c++20) and new optimizations and enhanced warning messages will be up-to-speed with the latest developments.

Exception support

Cheerp now supports throwing and catching of both C++ exceptions and ‘native’ JavaScript exceptions, allowing both porting of exception-based C++ codebases and easier interaction with any JavaScript library.

Here an example:

[[cheerp::genericjs]]
void someAlgorithm(void (*func)(int)) {
     //Some arbitrary code
}

[[cheerp::genericjs]][[cheerp::jsexport]]
void someFunction(void (*userProvidedCallback)(int))
{
    try
    {
        someAlgorithm(userProvidedCallback);
    }
    catch (cheerp::JSException& ex)
    {
        console.log(“There has been a native JavaScript throw");
    }
    catch (...)
    {
        console.log(“There has been a throw in the C++ code”);
    }
}

Once compiled, this code can be used in JavaScript like this:

someFunction(myFunction);
someFunction((a) => {if (a < 0) throw "Argh, a negative number";});

To enable exception support pass the -fexceptions flag at compile time.

ES6 modules support

Cheerp code generation has gained the ability to generate ES6 modules. This allows Cheerp-compiled libraries to be more easily included in module-based JavaScript deployments. The command line option -cheerp-make-module=es6 allows opt-in, with other options being commonjs, closure or no-module.

Example of usage at: https://docs.leaningtech.com/cheerp/ES6-Modules

Removal of -cheerp-cfg-legacy and cheerp-mode

We decided to discontinue two command line options.

-cfg-legacy had effect only in the selection of the internal stackifier algorithm. -cheerp-mode has been replaced already in Cheerp 2.6 by -target option that accepts either cheerp-wasm (the default) or cheerp (equivalent to -cheerp-mode=genericjs).

On our documentation the complete list of clang options.

Correctness, performance & size improvements

Following feedback from users and clients, we are always on the lookout for improvements to the parser, adding optimizations or improving code generation. In a year of work there have been plenty of local improvements that will be invisible but for the fact that error messages will be more informative, the code generated will be faster and leaner.

The other products developed by Leaning Technologies are all based on Cheerp, this means that all the experience we acquired by using our own technology over the last year is reflected in today’s release.

Partial Executer

In every release cycle we balance expanding the scope of the compiler with new features and improving it’s signature optimization capabilities.

We are very proud to introduce an innovative optimization technique acting at the LLVM’s IR level: Partial Executer.

We will soon write a more detailed article, but the basic idea is:

Given (partial) knowledge of the call-sites, it’s possible to prove that some edges in the Control Flow Graph are never taken?

If so, then it’s trivial to remove those edges and consequently remove unreachable BasicBlocks.

The basic idea expands on PreExecute, a Cheerp pass that uses LLVM’s own ExecutionEngine to try to complete the execution of the Globals initializers. If successful then it removes those calls while updating the global state.

Somehow similarly here we use the infrastructure that comes with the ExecutionEngine to execute Instructions coupled with a new components that navigates a function Control Flow Graph doing partial-execution starting from a given Call Site.

Practical example: printf. Printf takes a format string, that in most cases is known at compile time, plus other arguments that will be generally dependent on information available only at run-time. Can we partially-execute the printf logic that is dependent on the format string while skipping over parts that depends on the actual values to be printed? It turns out we can:

Current version of PartialExecuter is centered around discover edges that are never taken, but we believe this infrastructure to open up a whole new class of optimizations. Stay tuned.

Note: We will update the article to the detailed explanation. If you are curious, check the code: PartialExecuter.cpp.

Benchmark results

Emscripten, an alternative C++ to the Web compiler, has an extensive benchmark suite that we have adopted to provide fair comparison.

Benchmarks have been done between Cheerp 2.7 rc1 and Emscripten 3.1.5.

There are two metrics to be considered, total size of the generated output and execution time.

For each of the test-cases the sum of JavaScript and WebAssembly output has been computed, normalised to the maximum. Lower is better.

Execution time has been measured against the latest available V8 (the JavaScript engine that powers Chrome and Edge) and SpiderMonkey (Firefox), using the latest available packaged versions (v8 10.0.139 and sm 98.0b7). Timing has been measured on a server with TurboBoost disabled and using standard good practices to obtain benchmarks numbers.

Also here lower is better, and barring some inevitable noise, results should mostly be reproducible even in other settings.

How to install

For instruction and guidance, please visit:

Install: Ubuntu or Debian| Red Hat Linux| Windows | MacOS

Or build directly from source: Linux | Windows

To get started, why not follow one of the examples (here). Then just take some simpler component in your domain, write (or adapt) a simple C++ implementation, generate an equivalent component, and substitute the old piece with the new one.

Gitter or Github’s issues are the fastest way to get in contact.

If you prefer to check the code, the Cheerp fork of LLVM is at cheerp-compiler, while cheerp-utils, cheerp-libs and cheerp-newlib are external components.

Summary

Leaning Technologies is a technology company with extensive experience in solutions for the Web as a platform.

We participate in WebAssembly standardisation, pushing the standard to enable further optimizations (branch_hinting and soon tail calls), we improve browser engines (V8 and the recently started work on JSC), and we develop and evolve three unique WebAssembly+JavaScript based solutions: Cheerp, CheerpJ and CheerpX.

With Cheerp 2.7, we are giving developers access to the same powerful too we use to make the WebVM — an in-browser Debian terminal.

Update your Cheerp version, or give try it for the first time getting started on our documentation.

Join our Discord community or get in contact, to discover how Cheerp can bring your code to any browser.

For more of this follow us on Twitter and on our website. For additional information, please visit Cheerp’s documentation.

Thanks to Alessandro, Jules, Lorenzo, Serena, Yuri and Tom.

Cheerp 2.7: compile C++ to WebAssembly + JavaScript was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — We made a server-less virtual Linux environment that runs unmodified Debian binaries in the browser. This is powered by CheerpX, a WebAssembly virtualization platform. Feel free to play with it and report bugs: https://webvm.io

The web platform is well on its way to becoming the dominant platform for application distribution. While clear for a long time, this trend has accelerated since the standardization of WebAssembly: a new programming language, supported by all modern browsers and designed to fulfil the performance needs of large-scale Web applications.

WebAssembly brings real innovation to the world of browsers, together with a shift in perspective and responsibilities.

Engines are traditionally expected to squeeze performance from (potentially poorly) human-written JavaScript. WebAssembly, on the other hand, is designed as a compilation target. Achieving a high level of runtime performance is mainly the responsibility of the compiler generating it. When running WebAssembly, engines can avoid expensive checks and quickly generate high-quality native code. Ultimately, this enables the delivery of much more complex applications via the Web.

While the vast majority of WebAssembly-generating toolchains are native and used ahead of time, this is not a requirement. As a matter of fact, we believe that JIT-compiled WebAssembly is the real key to fulfilling the vision of running any application in the browser.

Here at Leaning Technologies, our mission is to enable running existing applications:

• without modifications;
• without recompilation;
• fully client-side.

A few months ago we released the REPL demo, proving that our CheerpX x86-to-WebAssembly virtualization technology could be used to run multiple different REPLs in the browser without any language-specific intervention.

Today we are proud to announce a major step towards realizing our vision: WebVM, a full Debian based virtual machine running in the browser, powered by CheerpX.

So, what is CheerpX?

CheerpX is a x86 virtual machine, written in C++ and compiled to a combination of JavaScript and WebAssembly with the Cheerp compiler.

CheerpX has been in development for over three years, and it is already used in production as part of CheerpX for Flash, an Enterprise solution to run legacy Adobe Flash content.

At a high level, CheerpX is composed of

• An efficient interpreter for x86 used to run rarely executed code and to discover the structure of hot code for the purpose of guiding JIT compilation
• A sophisticated x86-to-Wasm JIT compiler, that generates new WebAssembly modules on the fly from hot x86 code. Although the JIT compiler has some x86 specialized logic, it is mostly target independent.
• A Linux syscalls emulation layer is used to bridge the gap between the unmodified x86 binaries and the Web environment.
• A block-based filesystem backend, based on Ext2. Disk images are static resources distributed via HTTP and the CloudFlare CDN. Ext2 was chosen for its proven design and extensibility, and we can easily extend its features over time to be compatible with the more modern Ext3 and Ext4 formats without a full rewrite.
• Privacy-preserving storage for modified blocks, based on IndexedDB. This client-side-only technology allows any modification made to the filesystem to be persistent, but only to the browser. We don’t see or store any of your data.

CheerpX is a very complex system with many moving parts. It correctly deals with tricky situations such as self-modifying code, multithreading, multiprocessing, and inter-process communication. Notwithstanding this complexity, CheerpX has already reached a high level of stability.

Now it feels like the perfect time to release our most-complex demo, yet: WebVM.

So, what is WebVM?

If you have seen our previous REPL demo, you might notice that WebVM is not conceptually much different. The same core components are used:

• CheerpX as the execution engine. JavaScript APIs, in particular cx.run(…), are used to start (and restart if required) a bash process. bash can then start other processes as the user types commands.
• Xterm.js as the main UI component. Xterm.js takes care of interpreting terminal escapes used by applications such as vim, and also sends back user input into CheerpX. Input is made available to the applications via their standard input file descriptor.
• A Debian buster disk image, in the ext2 format and with a bunch of packages installed. This is distributed over a CDN to maximize scalability.

WebVM is effectively server-less and has no active server-side component. All users access the same disk image from the CDN, with their individual changes being preserved locally to the browser. This means that we could support even millions of concurrent users with minimal costs and resources.

Our previous demos were intended as snapshots of CheerpX progress and showcases of the technology potential. WebVM is different in that we consider this to be a living demo that we will evolve over time. Bug reports and feedback are very welcome, over multiple channels:

GitHub issues: https://github.com/leaningtech/webvm/issues

Gitter chat: https://gitter.im/leaningtech/cheerpx

CheerpX has been, so far, only exposed to users in a relatively controlled fashion. One single application at a time. WebVM is the first time we really give control to a wider public and we do expect problems to arise. But public feedback will make it possible to discover many more bugs and, ultimately, deliver a more robust solution.

What can I do with WebVM right now?

We think the demo will, most likely, speak for itself. If case you are unsure, try this:

# Run a short python program
python3 examples/python3/fibonacci.py

# Compile a small C example using gcc
gcc -o helloworld examples/c/helloworld.c

# Run it!
./helloworld

# Dump the code, to verify this is actually an x86 binary
objdump -d ./helloworld

# Edit the helloworld.c file, and try again
vim examples/c/helloworld.c

Example files for various languages are available in the examples directory. If, for any reason, you don’t like to use gcc, feel free to try clang as well!

Where can I run it?

WebVM and CheerpX are compatible with any browser, both on Desktop (Chrome/Chromium, Edge, Firefox, Safari), and Mobile (Chrome, Safari), provided support for SAB is present, and the device has sufficient memory.

Is this all?

This release of WebVM is really just a first step. We plan to improve and evolve WebVM over time, and feedback from users will be guiding our efforts.

In the short term, this is what the pipeline for the next features of WebVM and CheerpX looks like:

• HTTP servers (microservices): By combining Service Workers with virtualized TCP sockets, we will allow HTTP servers inside the WebVM to be reachable from the browser itself. A JavaScript API will be exposed allowing to connect an iframe to the internal servers. This is mostly supported already, although not exposed on the current demo page. A similar solution could be used to support REST microservices as well since Service Workers also handle fetch/XHR requests.
• Graphical Linux applications: CheerpX will soon allow Xorg applications to run in WebVM. Xorg communicates with X clients over UNIX sockets, which are already supported. To actually display graphics we will need to emulate a Linux device that Xorg can talk to. The best solution seems to be using KMS devices. Getting to a basic level of support for graphical output to work is mostly a matter of allocating a framebuffer that Xorg can use, and blit that over to an HTML5 canvas for display.
• Windows applications and games: Using WINE, which is a binary-compatible re-implementation of the Windows API libraries. Similarly to Xorg WINE uses UNIX sockets to coordinate applications with the wineserver, which is broadly equivalent to the Windows kernel. In terms of CheerpX support, there might be some fine-tuning needed for our mmap implementation, since WINE needs careful control over a process’ address space. Some specialized features of UNIX sockets, for example, passing of file descriptors, might also need some work. Still, all of these would be small improvements to the existing infrastructure.

We hope you’ll find WebVM as exciting as we do!

Join our community on Discord 👉 https://discord.leaningtech.com

Do you think that you have the perfect use case for our technology? Feel free to get in touch: https://leaningtech.com/contact-us/

WebVM: Client side X86 virtual machines in the browser was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Historically, JavaScript has been the programming language of the Web. This changed with the introduction of WebAssembly, albeit in a fairly indirect way. WebAssembly itself is not intended to be written manually. You certainly can do that, but similarly to traditional assembly languages, it’s really not advised.

WebAssembly is, fundamentally, a compiler target: a binary representation emitted by a specialized program from a different source language.

This is also reflected in the design of WebAssembly engines themselves, which assume that the incoming bytecode is already well optimized, and most of their internal optimization pipeline is disabled. This is in stark contrast to JavaScript compilation, where decades of work from the best minds in the field have been invested to make low quality JavaScript run fast.

At the time of this writing, WebAssembly is most commonly generated from C/C++ code using LLVM-based toolchains. When effort has been made to port modern dynamic programming languages, such as Python, the preferred solution has been to compile a C/C++ implementation. To achieve this, stripped down versions may be used, for example disabling JIT support or modules that depend on natively built components.

Porting a significant C/C++ codebase to WebAssembly is not necessarily a simple endeavor. A programming language implementation will most likely have multiple target-dependent code paths or definition, so the effort required is not dissimilar from porting the language to a new native architecture.

Then, of course, if after porting Python, you want to port Ruby… well, you need to start from scratch.

A better solution

It is already possible to find browser based REPLs for some of the most popular programming languages. Some of them are, more or less, complete ports of the corresponding engines from C/C++. Some other services “cheat”, by running the program somewhere on a cloud VM and only using the browser to interact with the user. Cloud based solutions are trivial to implement but also have significant drawbacks in terms of computational costs and user data ownership.

At Leaning Technologies, we like to build products that solve difficult, general problems and can support multiple use cases at the same time. An example is our flagship technology CheerpX, a WebAssembly powered Virtual Machine whose goal is to safely and efficiently run unmodified X86 binary code in the browser.

At its core, CheerpX is an emulator for the X86 architecture. Obviously a simple emulator will not get you very far in terms of performance, so we implemented a sophisticated JIT compiler that is able to generate efficient WebAssembly representations for hot code. The whole process is 100% automated and requires no metadata or assumptions whatsoever. The system is so robust that it can actually deal with applications that generate new code internally at runtime, and even with self-modifying code. This means that you can actually run things like NodeJS, including the full V8 engine with its remarkable JIT and code garbage collection.

As you can imagine, this is a fiendishly complicated problem. When designing CheerpX we decided to only focus on user-mode code (Ring 3), ignoring (for now) the complexities of system level (Ring 0) features. To close the gap and let real world applications run, we have implemented (a subset) of the Linux system calls interface.

By now it is probably clear that CheerpX can be used to run any programming language REPL in the browser. Instead of porting each language environment manually to WebAssembly, we simply let the whole Linux/X86 build run on top of the CheerpX VM.

To reach a satisfactory performance and UX, a couple of additional problems had to be solved:

Terminal output: CheerpX provides partial support for terminal interaction in the host web page. REPLs tend to use advanced terminal manipulation to enhance the user experience, most usually by including libreadline. Instead of investing effort in improving our terminal implementation we have decided, for once, to use an external library: XTerm.js. It works great in most cases, although we had encountered some issues with a couple of the demos.

Data storage: Our first iteration of these demos stored data by unzipping an archive into an IndexedDB powered file-system, with each entry in the database being a file or directory.

This solution did not scale well. Isolating the minimal archive to run a given REPL is, in general, an error-prone process. By shipping too few files we could cause runtime failures, while too many files would increase the download time needlessly. Actually, both situations could even happen at the same time! Moreover REPLs seem to like prodding the filesystem all over the place, with the worst offender being probably NodeJS.

We have seen even mildly complex scenarios attempting to access thousands of files. IndexedDB did not seem to be very happy about such access patterns.

The solution to this problem was to integrate a custom Ext2 implementation in CheerpX. Disks are represented by HTTP assets, which can be downloaded block-by-block and are cached by a CDN. Since only the required blocks are downloaded we can avoid any effort in optimizing the image size.

We were actually able to stop maintaining different images for each REPL. We can literally debootstrap a Debian setup inside an Ext2 image, install the packages we want and copy it over to an HTTP blob storage. Downloaded blocks are internally cached in IndexedDB to both reduce download time on page reloads while also allowing privacy preserving disk write support. Any data you edit with this configuration is private to your own browser. We don’t see anything.

Let’s see what we can do by putting all this machinery together, shall we?

Python3

REPL: https://repl.leaningtech.com/?python3

Python is an interpreted, high-level, general-purpose programming language. It’s dynamically typed and garbage collected. It supports both procedural, object-oriented and functional programming.

This demo features the standard CPython implementation, which does not include a JIT. It compiles the source files (.py) into intermediate bytecode files (.pyc). This is an interesting point: it means that whatever implementation of the underlying filesystem we use, it has to support persistent writes.

Somewhat surprisingly, we found a possible POSIX non-compliance in the way pyc files are written. In our first implementation of the write syscall CheerpX would only save up to a disk block, expecting the application to try again if data was only partially written.

We believe this to be allowed by POSIX, but real world code seems to have a different opinion. We have since then improved CheerpX to allow “unbounded” writes and reads. Generally speaking nothing can truly be unbounded, neither in CheerpX or on native, so we wonder if Python3 only works because the cache files are relatively small in practice.

But don’t worry, this bug is most likely not exploitable, and worst case it should be a denial of service. Nothing critical runs on Python right?

NodeJS

REPL: https://repl.leaningtech.com/?nodejs

NodeJS is a server-side JavaScript environment built on top of the state-of-the-art JavaScript engine, V8. A REPL is included, as usual, for convenience.

In the past, whenever we mentioned running NodeJS/V8 in the browser, we have seen people expecting a stripped down pure-interpreter version. That is not what you see here. This is the unmodified executable shipped with Debian, where the JIT is enabled and used.

Curiously, the Debian build is not as optimized as it should be. It ships a very thin nodejs executable whose only purpose is to load libnode.so containing the whole program. The shared library does not make proper use of internalized symbols, which means that most (all?) of the function calls happen via the PLT. After noticing this, we have improved the existing support for inlining and devirtualization in CheerpX to effectively convert these indirect calls to direct calls in most cases.

Ruby

REPL: https://repl.leaningtech.com/?ruby

A run of-the-mill interpreter. Nothing very interesting was found while working on this. One of my side projects is to actually run the full Rails environment as well, including opening rendered pages inside a separate iframe. This can be done and I have a working prototype already. If there is some interest we may get to publish it as well.

Cling

REPL: https://repl.leaningtech.com/?cling

C++ is not traditionally interpreted, but like any other programming language it is possible to do so. We used cling (https://root.cern/cling/), an interactive C++ interpreter built on top of LLVM/Clang and developed by CERN. It has a command-line prompt and uses a JIT compiler to evaluate the input line-by-line. Since it’s built on top of Clang, it can parse everything that Clang can parse.

It’s an extremely complex piece of software that adds to the normal C++ instructions a series of interpreter-specific C++ extensions aimed at making the use of Cling’s shell easier. It features an internal set of commands to print the current AST and to load and execute files. It additionally manipulates the user code into valid C++ code so that it’s possible to compile it with the underlying Clang.

Example:

cling$ int i = 1; fun(i++) // perfectly valid Cling instruction

Becomes

int i = 1; // global declaration

void wrap_0() { fun(i++); }

Of all these demos, Cling is the only one that does not ship by default with Debian. It was installed separately from archives provided by the developers. The cling executable itself is 100+ MBs. To get this monster to load in a reasonable amount of time we implemented lazy loading of ELF executables in CheerpX.

Most likely the excessive size is caused by the executable not being properly stripped of debug info. We could have stripped it ourselves, but since the point of this exercise is proving that CheerpX works on binaries without any intervention, we decided against it. Just be aware that this demo is not as speedy as others.

Lua / Luajit

(Lua) REPL: https://repl.leaningtech.com/?lua

(Luajit) REPL: https://repl.leaningtech.com/?luajit

Lua ships with a very simple interpreter that worked on CheerpX out of the box. Since we like to do complex stuff, we decided to add Luajit to the mix too. We understand it to be a completely separate project from the official Lua interpreter.

The main issue we found for these demos was user input handling. All the other REPLs use raw terminal input: they are happy to receive control characters such as backspace and newline and process them internally. Lua/Luajit expects cooked terminal input. Xterm.js is not designed for this use case, and has no line-editing support. We have worked the problem around by supporting keystroke echo on our side, and remapping the ENTER key to the expected character. Please note that full line-editing support in CheerpX is lacking, although it can be certainly implemented if need be.

What’s next?

Of course, we did not go through all the complexity of implementing CheerpX just for these demos.

CheerpX is the foundational technology to CheerpX for Flash, a Flash emulator to run legacy Adobe Flash content in pure HTML5. CheerpX for Flash works by running the Flash player (an X86 binary for Linux) in a way not dissimilar to what we have shown in this post.

We believe that the REPLs themselves may be useful in the education / training sector, or to let users fiddle with any library (for any programming language) directly from the documentation page. If this sound useful to you, or you have even better ideas, get in touch: info@leaningtech.com

But, really, this is intended to be just the first step of a much more ambitious demo. As we said, we have a full Debian disk image, with dozens of packages installed, and a solid solution to run a single app from it. We want to get to a point where we can drop the users into bash, and let them do what they want.

We are talking about an always available, zero-cost, virtual machine with guaranteed data privacy.

Does that sound not interesting enough? Well, what if you could spawn XOrg and graphical applications on top? What about a full desktop environment?

I hope this is as exciting for you, as it is for us. And if you think you have the perfect use case for our tech, let us know.

https://twitter.com/alexpignotti

https://twitter.com/leaningtech

https://leaningtech.com/

info@leaningtech.com

CheerpX: Using WebAssembly to run any programming language in the browser was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.

A bit of a “learn from our pain” / rant / sharing our experience-type blogpost, but here goes.

At Leaning Technologies, we make compilers and VMs that target JavaScript and WebAssembly. Our tooling is used both to extend the life of existing applications allowing them to run on modern browsers, but also to port and develop new web applications in languages that are traditionally a prerogative of native applications (such as C/C++ and Java).

As we typically work at the limits of what modern browsers and HTML5 specs allow, we have found (and fixed!) more browser bugs than we’d like, helped improve the performance of more than one JavaScript engine, and are an active part of the standardization process for WebAssembly.

Generally speaking, we work in a niche where it’s easy to develop PoCs and small toy projects, and very hard to make robust products. Having a majority enterprise clientele, but also because of our nature, we are the sort of people that always try doing things The Right Way™.

CheerpJ, in particular, is our solution to convert and run any Java client application, fully client-side, in the browser. And when we say “any”, we mean: reflection, proxies, dynamically generated classes, full runtime support (AWT, Swing, etc), threads, you-name-it. CheerpJ is the only tool in the market with these capabilities, and is mostly used by enterprise customers with complex porting and migration requirements.

As an offshoot of this technology, we have for several years offered a free-to-use Chrome extension (for non-commercial purposes), called CheerpJ Applet Runner.

This lets users seamlessly access fully deprecated Java Applets on modern versions of Chrome, without a local Java installation, or a plugin. This is achieved, in essence, by converting the Applet bytecode to HTML5 on the fly, and providing a full Java runtime environment in JavaScript and Wasm.

Originally developed to have our tech tested as much as possible in the wild, it has become very widely used by people, from all walks of life, who still need to use Java applets on a daily basis. We have helped over 40,000 students, senior card players, artists, law enforcement officers and even major US federal institutions to access content that is way past its selling date. And with a 4.4/5 rating and wide adoption, I think we have been quite successful at that.

Not the best way to begin your day

In March 2020, as the COVID-19 pandemic began to rage over the planet, I woke up one day to find what any extension developer dreads the most. Two emails, in rapid succession:

1. Your recently published update was rejected for policy violations;
2. Upon review, your product was found to violate our policies and it has been removed from the store.

The second email offered us a shimmer of hope: it was possible to reply and appeal to the decision, which we immediately did. We received an automated response that, due to the (at the time) new pandemic and general congestion of the Chrome Web Store, it might have taken a few days to receive an answer.

Almost 18 months later, we are still to receive an answer to our appeal. The extension is still up on the store somehow, with a Rejected update in the Dashboard. Because of this, we have decided not to update the extension, or try again with the same update, being worried that the extension might be taken down altogether.

What this has meant was leaving users with unresolved bugs, and leaving us without the extensive testing that only thousands of end-users can provide to our new releases. Not only that, but there have been several major releases to CheerpJ, the big-sister technology behind this extension, which we have not been able to propagate to the Applet Runner.

After such a long time, we can’t postpone updates any longer, and can’t continue stalling.

This post is about our plan to get out of this quagmire, about the inevitable costs of this situation (both for us and our users), and the massive amount of frustration, pointless limitations and ugly bugs that we have found along the way. Hopefully, this will be useful for other developers of Chrome extensions. At the very least, they might find some comfort from seeing other people having their fair share of pain.

Are we the bad guys?

Chrome Web Store policies change frequently, mostly getting stricter by the day, and for very good reasons.

Extensions are powerful, and can easily have a serious negative impact on user security and privacy. This can happen both directly (i.e. a plain malware/spyware extension), but also indirectly, by compromising the developer account or remote assets of an otherwise legit extension.

There is also the grey area of “extension acquisitions” by shady companies: we very regularly receive inquiries to purchase the CheerpJ Applet Runner extension, most of them not looking exactly kosher.

Anyway, as a form of defense in depth, the Chrome Web Store policies require that the least possible amount of permissions are requested. In this way, even a compromised extension can still do limited damage. This makes complete sense. Extensions developers are incentivized by a “warning” system: when installing an extension a worrying message is shown to the user if the extension requires heavy-handed permissions. Moreover, developers have to justify each and every requested permission when submitting an item to the store.

For us, the idea of sticking to these guidelines not only made sense — it was a no-brainer. We care hugely about user privacy, and we certainly do not want our users to think that CheerpJ Applet Runner will “read and change all their data on the websites they visit”. To be fully honest, we don’t even want the responsibility that comes with that.

That said, our extension needs to be able to do some tricky stuff just to work as expected. In particular:

• Many Java powered websites will try to detect if Java is supported before creating the relevant <applet>/<object> elements. Plugins have been unsupported in modern browsers for quite a while at this point. To work around this, the extension needs to “spoof” that the plugin exists, to let such pages fully load. Usually, this check is done synchronously and very early in the page life cycle. For this reason, the extension needs to be able to inject the spoofing code very early.
• It’s not possible to predict which domains may still use Java applets. They could be anywhere, although most likely not on major, well maintained sites. We know from user’s bug reports that an immense number of obscure pages still include Java applets. Inevitably, our extension needs to be able to run (potentially) on any website, but should only be actually enabled on the small subset of domains that the user requires.
• Finally, our extension needs to do the magic trick of “converting and running Java Applets” as HTML5 in the browser, without a plugin. While this is our bread and butter, and we know this is not only possible, but also safe to do, we can imagine that an overworked extension reviewer may have a different impression, and with little time available may just opt for the safer option of declining approval.

We don’t need no weird permission

With quite a bit of effort, we settled on the following permissions scheme, which worked well for us for years, up until the unsettling emails of March 2020.

• optional_permissions <all_urls>: Our solution to let users run the extension on any domain, was to use optional_permissions. This feature allows extensions to declare the maximal amount of permissions needed, without having them actually granted at installation time. In terms of UX the user will need to selectively enable CheerpJ Applet Runner on his chosen useful domains, most likely just a handful. This is done via a single click in the extension popup. The extension would then be automatically enabled on any follow-up visit to the same domain, as Chrome will remember the granted permission. The user is always free to drop permissions, by using the standard Chrome UI.

• declarativeContent: This permission was used to provide a visual hint whenever a Java applet is detected, or about the status of CheerpJ when already enabled. Using the declarativeContent API it is possible to select different icons depending on which CSS selector matches on the page. This is fully privacy preserving, since the extension only declares the rules to the browser, without actually accessing the page contents. Ideally, this behavior should be specified statically in the manifest.json file, and no permission would be required. Unfortunately, specifying icons in the manifest is only possible using a deeply undocumented base64/binary format (which I managed to figure out only recently). Not that it matters, since the whole feature has been completely broken since April 2018, without anybody noticing.

• activeTab: A very lightweight permission, just used to query the current tab id and bootstrap the process. Although using activeTab is recommended, and possibly the least invasive thing you can ask for, Google still requires a justification for using it.

No good deed goes unpunished

To the best of our understanding, by following this scheme we were playing well within the rules. Certainly above the industry average. Getting so close to losing our extension after all this effort has been very painful and frustrating, and has essentially forced us to delay updates for a very long time, to avoid risking the extension being banned.

My best guess about what happened is a change in policy that made remotely hosted code frowned upon, and fully banned in the upcoming Manifest V3 revision of the APIs.

CheerpJ runs Java, and as such, it needs a full ‘equivalent’ of the Java runtime. In CheerpJ, this is provided as a fully static set of JavaScript/WebAssembly files, distributed by us on a CDN, with each version fully immutable once published. The extension itself is very lightweight, with most of the actual logic being provided by the remote modular runtime. Of course, all this logic would run in the context of the page,

The Chrome Web Store process for submitting extensions does allow developers to justify whenever permissions are required. As much as we believe that the CheerpJ Applet Runner already plays by the rules, we also suspect that our use case is just too unique and unexpected to be fully understood in the limited time allocated by reviewers.

Moreover, as far as we understand the extension is currently living on borrowed time, and it is very unclear if another rejected update may cause it to go down for good. We have tens of thousands of users which may need this tool, and we don’t want to let them down.

This is our plan to update the CheerpJ Applet Runner extension, in the hope of a successful and quick review and approval on the Chrome Web store.

The plan (1/4): Be as light as a feather

As you can imagine, we are extremely worried about the risks of getting the next update to the CheerpJ Applet Runner rejected, and about the risks of the extension getting taken down for no reason.

To make sure to avoid a second rejection, we have decided to re-engineer the extension to reduce the permissions required to its absolute minimum. Ideally to zero.

This has come with a cost that we were previously not happy to pay, but can’t avoid any longer. In particular, new versions of the extension won’t be able to use the “enable once / run always” feature. The user will need to click the extension icon every single time he needs to use an applet.

To minimise the required permissions, and hopefully maximize the chances of getting the update approved, we had to make several major changes:

Adopt Manifest V3: Manifest V3 is a new revision of the Chrome extensions platform, which introduces new rules and limitations to enhance user security and privacy. Using V3 is currently optional, as V2 is still supported, but it’s clear that at some point in the future V2 will be deprecated.

We decided to adopt V3 in the hope that its stricter limitations will make the revision process more straightforward and less subject to arbitrary decisions from reviewers. Moreover, we are also future-proofing the extension to a future deprecation of V2.

Include the whole runtime in the extension: This is a requirement in manifest V3, since remotely hosted code is now banned. Previous versions of the CheerpJ Applet Runner used to fetch individual runtime components from a CDN, on demand. This avoided unnecessary downloads when only small parts of the runtime were required.

Technically, this limitation is enforced using very strict Content-Security-Policy requirements in the extension manifest. To be fair, this might be an improvement for some users on slow connections. On the other hand, we will need to be more careful in planning our updates, as the extension is no longer a few kilobytes, and we don’t want to spam our users with large background downloads.

Drop Google Analytics: Previously, the CheerpJ Applet Runner used GA for very minimal tracking of usage (not users), with a single-click opt-out, and no logging of URLs.

Due to the new CSP, loading the normal GA script is forbidden. It would have been technically possible to use GA (or another analytics provider) by bundling the script with the extension, or by just sending events manually. Nonetheless, we went one step further and decided to drop any form of tracking.

Drop optional access to any host: This is the most expensive choice we had to do in terms of UX. As far as we understand a special review process is imposed to extensions that use <all_urls>, even if only as part of the optional_permissions section.

To avoid this more in-depth review altogether, we are dropping this capability, and that’s the reason why enabling the extension only once for a domain is not possible anymore. We have devised a new approach, and we will only use the activeTab permission to inject our loader script into the currently used tab.

One of our biggest disappointments was discovering that the whole concept of optional host permissions has disappeared with Manifest V3. The manifest format has been reorganized to have permissions, optional_permissions and host_permission, with all hosts being considered non-optional right now.

There is some vague wording about making all host_permissions optional in the future, but as things stand right now it is impossible to make a Manifest V3 extension that can potentially run on any host without triggering the scary warning at install time or forcing the user to enable to extension any single time even for the same domain.

Drop the storage permission: CheerpJ Applet Runner has pretty much only one setting that requires storage: which clipboard mode to use (a single binary value). Storage used to be one of those permissions that required no justification. This has now changed, but we have been able to find a new strategy and use the localStorage feature of the private extension domain to save these settings. This has not been trivial, since for reasons which are hard to fathom, localStorage is not available in the background service worker that powers extensions.

Drop declarativeContent permission: Programmatically adding declarative content rules was used for two reasons. First, it made it possible to automatically inject the CheerpJ loader scripts after a domain was explicitly enabled once by the user. As discussed above we have sadly dropped this feature anyway.

Secondly, it was used to provide visual feedback to the user about the status of running applets by changing the colour of the extension icon. In particular we would use CSS selectors as triggers to show a yellow icon if Java applets were detected on a page, and a green icon if CheerpJ Applet Runner could successfully run. The great thing about declarativeContent, is that the extension only declares the rules, and the browser does the matching. This means that the extension does not need to peek into the page, and user privacy is preserved.

As crazy as this might sound, dropping this feature had no real cost since the whole thing has been completely broken in Chrome since April 2018! We have actually bisected the issue and found out that a single line of code was misplaced as part of a maintenance commit. And that’s not all, even after fixing this two-liner on our side, we have found out that the feature broke again at some later point. How this feature could stay broken for so long (and even break TWICE) without anybody noticing goes beyond my understanding, and I wonder if the extension platform of Chrome is actually held to the same high standards as the rest of the project.

After all these, somewhat painful, choices we are left with an extension that only requires the activeTab and scripting permissions, which work together to spoof the availability of the Java plugin, and inject the CheerpJ loader in the page. There is nothing else we can remove at this point, and we can only hope that the review deities will appreciate our sacrifices and be kind with us.

The plan (2/4): Prepare for the worst

Even with all the precautions that we have taken, unfortunately we can’t be sure that CheerpJ Applet Runner will not be taken down by the Chrome Web Store.

To make sure that another option is available to our users, we have just released the CheerpJ Applet Runner on the Edge Add-ons Store. It is safe to assume that the vast majority of users will be on Windows, and Edge will be already available on their Desktop anyway. Edge is currently just a fork of Chrome, so this has not required any further technical effort on our side. I have to say that the review process was fair, speedy and efficient.

We have also prototyped extensions for Firefox and Safari. As things stands, though, manifest V3 is not supported by either, so we would need to provide a specifically downgraded version for them. At this time we have decided against supporting Firefox/Safari, but we plan to revise our decision when V3 is supported. Firefox in particular has announced a beta of the feature later in 2021/early 2022.

The plan (3/4): Make some noise

The main point of this post is to be open about the whole process of maintaining and updating a Chrome extension.

As a consequence of the “difficulties” of this process, the next version of the CheerpJ Applet Runner will have to be a significantly inferior UX compared to what our users are used to. I felt we owed an explanation as to why this is the case.

We hope that this post will raise awareness on the very sorry state of the Chrome Web Store, and of the approval process for updates. We are not the first developers to be negatively impacted by the extension review process (and we won’t be the last), and we have seen how, in previous cases, getting some attention from the community can go a long way. Hopefully this will apply to the CheerpJ Applet Runner as well.

The plan (4/4): Roll the dice

Once updated, we will try to reintroduce some of the lost UX, in particular we’d like the declarativeContent support in Chromium to be fixed, so that we can restore the use of color-coded icons to better inform the users.

Having found the issue, and once a fix gets applied to Chrome (things are not looking particularly promising by the way..), it will take around a couple of months for the patch to trickle across the release cycle.

About requiring a click every single time you want to use the extension, while not ideal, we don’t really see a way to avoid that. Any proper solution would require heavy handed permissions and warnings, especially with Manifest v3 having dropped optional host permissions. We have hopes that future revisions of the APIs will restore this feature.

If you can think of a good way of solving the problem, I’d be very interested to chat. Feel free to ping me on Twitter.

The end, for now

If you made it to the end of this post, thanks a lot for your patience.

If you have any ideas or workarounds for any of the issues described in this post, or you have your own Chrome-extension related woes, please get in touch with us, we’d love to chat!

{Twitter, Gitter, website, email}

And if you want to know even more about what we do you can find plenty more to chew on, visit our tech blog!

The Bottomless Pit of Disappointment: A Chrome Extension Tale was originally published in leaningtech on Medium, where people are continuing the conversation by highlighting and responding to this story.