Podcast: WebAssembly on the JVM: Feature Evolution, Performance, and the Transition to Endive

Andrea Peruffo discusses the evolution of WebAssembly beyond the browser and its growing role on the server-side JVM. He covers performance advancements in Wasm runtimes, moving from interpreters to efficient JIT compilation, and explores real-world production use cases ranging from edge computing platforms to modular plugin architectures. Peruffo also announces the transition of the Chicory runtime to "Endive" under the Bytecode Alliance, detailing the shift toward foundation-governed development to ensure long-term stability and neutrality in the JVM ecosystem.

Key Takeaways

WebAssembly provides a secure, sandboxed execution environment on the JVM, offering a portable and safer alternative to JNI for running non-Java code.
Runtime performance for Wasm on the JVM has significantly improved through advanced compilation techniques, moving from pure interpreters to JIT compilers and Cranelift-based assembly generation.
The Wasm Component Model and WASI standards enable sophisticated interoperability, allowing developers to compose applications from diverse language ecosystems (e.g., JavaScript/QuickJS, Ruby/Prism).
WebAssembly is proving effective for enterprise-grade production use cases, powering edge computing platforms and enabling modular plugin architectures for tools like Helm 4 and Microcks.
The transition of the Chicory runtime to "Endive" under the Bytecode Alliance signals a strategic move toward foundation-governed, community-driven development to ensure long-term stability and neutrality.

Subscribe on:

Transcript

Olimpiu Pop: Hello everybody. I'm Olimpiu Pop, an InfoQ editor, and I have in front of me probably one of the jolliest software developers I know. And that's Andrea Peruffo. Andrea is a long-running developer, did a lot of interesting stuff, but I'll let Andrea introduce himself.

Andrea Peruffo: Hello everyone. Thank you, Olimpiu, for having me. Such an honor to be here. I am in software development since 20 years now. I have done a ton of things, especially on the JVM with Scala in the past and with Java more recently. Bring a WebAssembly on the JVM. That's probably what you have heard more recently by me.

Olimpiu Pop: Yes, exactly. But most of our conversations in at least the last two years were very niched if you want, even though it's debated about how niche it is. And that was mainly about WebAssembly and the fact that you joined the wagon of the guys that think that WebAssembly shouldn't be in the browser, just in the browser, and you can use it on the server side given your pedigree with Java.

But let's take it one step at a time. Why do we want to take WebAssembly out of the browser? Because it was very known for its JavaScript side. And let's take it to that. What's WebAssembly?

Bringing WebAssembly to the Server Side [01:58]

Andrea Peruffo: Well, who doesn't want a free lunch? I do. So, everything that has been developed for WebAssembly in the browser is theoretically reusable over server side. And on the front end, following the specification of a W3C, we have a WebAssembly that is used in each and every application that we are using nowadays if they are complex enough. For example, it powers Google Maps, the entire Google Docs suite, and the productivity tools. They are all backed by WebAssembly.

So, what happened is it born for the front end to give almost too native speed to some boxed environments in the front end and in the client side. But everything that has been built for this platform can be reused on the backend. And I think this is the most powerful thing. This was one of the main reason that drive me to look more heavily into WebAssembly. I don't like to rewrite stuff. I do enjoy to reuse as much as possible. And when I looked at the technologies that were available, WebAssembly stand out as the tool that enables you to have a bigger and wider impact on what you're doing.

Last year, I have been able to deliver and release databases, programming languages like CPython, JavaScript to enable running various kinds of Rust and C libraries, a protobuf. You can run a ton of really useful things without having to rewrite them. So, with just a very, very, very thin wrapper layer, and you don't go outside of the JVM with all the headaches that the JNI has. So, that's a pretty natural choice if you want to enable more workload and more interesting stuff on the JVM.

Olimpiu Pop: Okay. So, in those particular cases when you normally call from Java native libraries, now you can just use WebAssembly to just put together and make your life easier, maybe not just easy, but I think it's safer because that's the big ask and the big promise of WebAssembly.

Andrea Peruffo: Yes. And not only safer, safer because it runs, of course, with a different API. So, all your program is protected against the CVEs that the libraries that you are embedding will have, but also around the portability. When you have JNI, you have to pre-compile your native library for all the target OSs and architectures. But with WebAssembly, you have just one target.

And targeting WebAssembly means you have a fully portable JAR at the end of the day that you can reuse wherever the JVM can go. So, you have portability, you have safety, and it's far easier than doing JNI where they crush your JVM, and you have all kinds of misbehavior. I have done JNI for enough years in my life.

Olimpiu Pop: Okay, fair enough. So, now it's a vengeance against JNIs, and you show them how the things are going. I have to admit, I wasn't paying attention to what happened in the WebAssembly/WASI space. I know that one year ago, I think the last time when we met in person, there were a couple of big things that were happening. Maybe let's do a summary where WebAssembly is in terms of the standard and what happened on the WASI side. And also probably your pet project, Chicory.

Current State of WebAssembly and WASI [05:40]

Well, it's not pet anymore because it's a full-scale project. It already has I think two, three years since it reached the version one. But let's take them one by one. Where is WebAssembly now? What are the most important things that will happen in the WebAssembly/WASI space? Because obviously, in order to have something useful, the WASI interface to the system is quite important. Otherwise, we wouldn't be able to do many things on the server side.

Andrea Peruffo: Where we stand on the WASI side is that the core specification has been basically completed. So, they integrated all the proposals, what was called the proposal of WebAssembly, that were necessary to get more languages to run on the platform.

So, WasmGC garbage collection is integrated, as well as multi-memory as well as many other. And those proposals create a solid foundation. It's called the Wasm 3, the 0.3 release and is the core foundation that enables anything else on top of Wasm. In Chicory, we are compatible with all those specs, or most of them, whatever makes sense on the server side. And we have also an initial implementation of WasmGC. What does this mean? But you can run again on the JVM, going through Wasm languages like Scalas with Scala.js that can compile to WebAssembly GC, or Kotlin, or Dart, or those kind of languages.

So, we have enabled a new class of languages to be able to run on top of the WebAssembly engine. Talking about WASI, the system interface is being completely reworked. So, it has been almost finalized the WASI P2 and they are working on WASI P3, which integrates the Component Model, and the tooling and the toolchains are picking up the job to be enabled with it. What does Component Model means? Means that you can write the interfaces of your program in a WIT file, an interface file, and generate all the rest to compose your application with any other WebAssembly components, which is really fascinating.

And I'm looking forward to see how this plays in practice, where we will have a lot of different modules coming from different ecosystems that working goal together. So, that's pretty exciting work that has been done. I cannot wait to see how it play out.

Olimpiu Pop: So, if we look in terms of the versions and not only at Chicory in the Java, they are quite advanced. I'm talking now about WebAssembly targets for a lot of the other programming language. Wazero, I know that is one of the seniors of the space. Chicory is not far behind because it's already a couple of years now since it's already number one in terms of versions. But do you know anything about the adoption in production? Is it used, and where is it used, to just get more a bit concrete in terms of use cases?

WebAssembly Adoption in Production [08:46]

Andrea Peruffo: The biggest use case for WebAssembly in general has been exploited by all the major CDN provider. So, if you look at Cloudflare, Fastly, and Akamai, they basically are built in ours, or both companies that were able to run WebAssembly workloads on the edge. This means that the offering of Durable Objects by Cloudflare and compute at the Edge by Fastly and Akamai, as well, they all run your code on WebAssembly, which means that there is no other technology that is able to run this kind of workload in such small armor and with such a high density and security for the provider.

So, the providers are able to let you deploy your random applications on their infrastructure, and they are able to run it thanks to Wasm because Wasm, the very lightweight sandbox of WebAssembly, plays a great role in this picture and enables you to run whatever workload you want without risking to affect the underlying platform.

So, that's where WebAssembly already won. In the front end, of course, is used by all measure sites that has some CPU does its tasks to be done, if you need to do any rendering, any kind of cryptographic algorithm, or any kind of CPU-bounded computation, you are probably using WebAssembly embassies.

And on the server side, there are various usages. For example, you touched on Wazero. Recently they announced that Wazero is integrated in Helm 4 so that you can customize the behavior of Helm by injecting WebAssembly plug-ins.

So, it is enabling plugability of different systems on top of the platform. For example, talking about Chicory powers CPython UDF functions in Trinodp, which is a SQL database written in Java that is used for when you have a lot of data and is a great database, and it enable you to write CPython functions powered by WebAssembly in production since a couple of years now since our first 1.0.

Olimpiu Pop: Nice. Also, I know that a couple of months ago you had a bit of a collection of interesting things that you put together in running on Chicory just to see where it goes. One of the very important aspects for the global community is you managed to put DOOM, the vintage game, to run in the WebAssembly. I suppose there are other less important things that you manage to achieve, but this is quite important. Maybe you can share a bit about this experience and if there are other that you want to mention.

Real-World Use Cases: Doom and Prism [11:44]

Andrea Peruffo: Yes. Actually, DOOM was one of the first workloads that we got to run, and we were pretty excited about. Someone did an hackathon and portrait due to run on GraalWasm, which is by GraalVM folks. And we got it to run on Chicory pretty easily at the start of a project.

One of other projects that are really close to my art is a Prism. Prism is under the Ruby organization on GitHub, and Prism is a Ruby parser written in C that is powering JRuby. Basically, we have been compiling this Ruby parser to Wasm and executing it in Java since day zero.

Basically, we have both friends who are Charles Nutter and Thomas Enebo, which are the leadership of JRuby. They want to enable JRuby to run anywhere, of course. And the first thing that you have to do when you want to run JRuby is to parse its syntax. But the syntax of Ruby is done for humans and is extremely hard to parse it.

So, what happened is that in the various ecosystem, multiple parsers have been rising and falling along the years, and very recently decided to invest all their money into making one single parser that will be the official one. And this one is called Prism. And we wanted to be able to parse Ruby syntax on any JVM without having to install native libraries. That's why we started with Chicory.

And the cool part is that this project is following along the years the evolution of Chicory. This real-world C-Parser was one of the first payloads that we got to run on the interpreter at the very start. We improved performance 10x by using the compiler to Java bytecode. And I recently released a new compiler which instead produces a pure assembly that again increases 10x performance again on Prism, making it very, very competitive with a native version of it. This is just one of examples. I have millions of other examples if you want.

Olimpiu Pop: I know that you're a chatty Italian and I'm a chatty Romanian, two Latin Zoom meeting to talk, but one million it's a bit too much. So, if you have any other ones that you want to push forward, I remember the one with Prism. I know that it was mid last year. You're quite proud of it because it was the first one that was really making something important on web.

Running JavaScript on the JVM [14:23]

Andrea Peruffo: There is one that I really want to mention, which is a QuickJS. So, if you look at the Java landscape, there is basically no way to run JavaScript inside the Java application without using a non-deprecated library because Rhino and Nashorn, they are both deprecated, and the only alternative is GraalJS. If you are on GraalVM already, great, go for it. But if you're not on GraalVM, might not be a great fit for you.

And on other side, we have Shopify, which is a big portal that enabled you to run your shop and customize it with WebAssembly functions, as invested a lot on a little edge called the QuickJS. This little engine called QuickJS is written in pure C and very Rust bindings. And thanks to the Javy project by Shopify is extremely easy to get it to run on WebAssembly.

So, I took it, I embedded it into Java interfaces, and I got to apply it in a few projects. For example, Microcks is a project for doing API mocking, which is part of CNCF. And it happened to be a Spring Boot application. They wanted to integrate with an external language to let the user plug in their behavior, and we hooked up very quickly QuickJS and provided the functionality.

It was quite amazing because the last conference I was giving a talk in one room, and in the room next to mine, guys from Microcks were teaching people in a workshop how to use JavaScript on top of their platform. They were using the functionality without people noticing because this is something that Wasm is probably due to. It won't go for the hype, but it will power underlying libraries but would be otherwise impossible.

Olimpiu Pop: Okay. So, the key takeaway from here would be that if you want to incorporate in JavaScript, for instance, well, anything coming from the JavaScript ecosystem in JVM safely, Wasm is the way to go. And I cannot pause this topic to just underline our age, given that we both know what Rhino is in Nashorn is, because Nashorn was closer to the current moment, but Rhino was back in the day, maybe more than 10 years ago. I don't remember exactly when, but let's say we are wiser.

Andrea Peruffo: If you want, the fall part on this story is that at some point, talking about Rhino, Rhino tries to stay on the wave of a latest stack ECMAScript specification. But WebAssembly is part of that ECMAScript specification. And they ask us to be the WebAssembly engine behind the Rhino.

Olimpiu Pop: Rhino means just the interface, but behind the scenes it actually is WebAssembly. Okay. Probably it's the inclination of the younger generations for vintage games. So, it's like you'll see the younger folks having Mario in their hands.

Andrea Peruffo: Something that I wasn't expecting is that on top of Wasm and Java, a lot of people coming from Minecraft came to the project.

Olimpiu Pop: That's interesting.

Andrea Peruffo: I wasn't expecting that, but it happened to me quite a few times to debug graphical user interfaces showing Minecraft mods and stuff that I have no clue about.

Olimpiu Pop: That's interesting. It seems to be a quite good educational path. A couple of weeks back I was talking to Alex Zenla, the CTO and founder of Edera, and she was pointing towards Minecraft being the starting point of her programming career. And that made her think about several stuff, and she was comparing the Minecraft world. Well, I don't know what they're talking about, Andrea. So, we are two in this conversation, so I'll have a conversation with Alex, and she'll probably explain more about it, but it seems it's very lucrative. So, yes, maybe we should look into that.

Andrea Peruffo: Really? Okay.

Olimpiu Pop: You mentioned the workshops. And I think two years ago I was in your neck of the woods, well, more or less in Coimbra, you gave a workshop there, but also a talk. And I remember that in your workshop, it was putting together a couple of things as a parser. So, maybe in the end, that's what Chicory is. If you just break it down to the basic stuff, it takes things on one side and then spits other things on the other side. So, I know it's oversimplified, so that's why I want to invite you to tell us what actually a Wasm runtime means.

JVM Execution Strategies [19:02]

Andrea Peruffo: Yes. So, we have different layers where you can execute the code written to Wasm. So, the first one that we implemented is a pure interpreter. A pure interpreter will take instruction by instruction from your WebAssembly program or function and will execute them directly on the JVM without doing any kind of pre-processing. This is extremely portable in the sense that it is self-contained and is fully built on the standard library for us. So, this is extremely portable, can run on Native Image, it can run in the most strict environment, and works everywhere.

The bad side of it is the fact that it's extremely slow. We are not applying any kind of performance improvement on top of the interpreter because it is anyhow inherently slow. It has to process instructions one by one without a chance of getting JVM C1 or C2, just-in-time compiler, to kick in and improve the performance of the WebAssembly panel. What we have developed after that is a full-blown compiler from WebAssembly to Java bytecode. If you look from far enough, you can see that WebAssembly bytecode and Java bytecode, they look very, very similar.

WebAssembly has structured control flow, while it's unstructured on the JVM, but we are going from a more constrained environment to a less constrained environment. So, everything is not a really bad transformation. And we do it almost in one pass... We do a direct translation from WebAssembly to Java bytecode.

What we observed is that once you start translating all your functions into generated Java functions that will map the original WebAssembly, they will start to get optimized by the just-in-time compiler, C1 and C2. And they will eventually become very, very fast on the JVM after a number of iterations and almost match the performance of native compilers that will target native assembly.

This is the second tier, and this compiler can run both at runtime by linking the new program using a very, very thin layer of reflection that you need to enable if you want to run it in a restricted environment. Or what we are using most of the time is, if your WebAssembly payload is always the same, imagine QuickJS, the engine is always the same, so you just need to compile it once to WebAssembly, and then from WebAssembly you compile it to bytecode. Once you have the bytecode, that bytecode is fixed, and you can just take it, ship it, and reuse it without having to do an additional tweak or tune on top of it.

But said, what happened is that I have been pitching the fact that running everything fully in the JVM is a great strategy and really great for your application, that will not cause any harm or any hang of your program, but people were constantly looking for performance.

We got a number of reports where people tried to run things on the interpreter or even on the compiler, and they said, "Okay, this is not as fast as Wasmtime. This is not as fast as V8 or the browser". Given that experience, I wanted to do the next step. So, I have a new experimental compiler that got announced at last Spring I/O, where we actually rewrote the compiler, but not rewriting it from scratch.

So, Wasmtime is a very famous runtime for WebAssembly written in Rust. And it uses, behind the scenes, a compiler from pure assembly, machine-specific assembly code, which is called the Cranelift. Instead of doing the entire job of writing a multi-pass compiler ourselves and embarking in this multi-year project, we just took Cranelift, compiled it to WebAssembly itself, because it's just pure Rust, so we can reuse it in pure Java again, and using this Cranelift compiler to pre-compile to specific assembly of your WebAssembly program.

In this way, we have performance which are basically the very same as running on the Wasmtime, which is the state-of-the-art runtime in WebAssembly land. So, this gave us the last mile of speed without having to ship any native library because we are not linking against Wasmtime, but we are just basically reusing the compiler from WebAssembly that stands behind Wasmtime.

Olimpiu Pop: If it will be to rewrite Chicory, what would be the thing that you would do differently? I know that one of the things that you mentioned out initially was the fact that Chicory is pure Java. This comes from, let's say, the zero family, because there are plenty of people that are obviously now zero dependencies is quite important, as we see a lot of problems occurring on the supply chain attacks and so on and so forth.

But I spoke with Gunnar Morling not long ago, and he was underlining his new project, Hardwood, that is a library that has a very small number of external dependencies. So, it seems that this is getting more and more important these days when people are actually caring about these points.

Chicory Design and Security [24:39]

Andrea Peruffo: Well, I don't know what I will do differently in Chicory in the sense that we have been developing it with safety in mind first, and then we got to performance, which is, I believe, still the most useful path for our users.

Everything that is running on top of Chicory depends on a very, very limited number of external libraries that are built themselves on top of the Java standard library. So, there is very, very thin dependency, and even the code that gets generated is usually much smaller than the original Wasm. So, I think at the moment we have a very, very good runtime with performance that are matching the state of the art and with a security and with a history of being in standard Java, which is great for the project. Yes, not sure what I would do different.

Olimpiu Pop: Okay. Well, that says a lot about you because you are very opinionated and you have an opinion about most of the things in terms of programming. So, then that says a lot, Andrea. So, it seems that you're very happy with what you guys managed to achieve.

Local-First Software and Cloud Architecture [25:49]

I don't know if you know about that test scenario. If not, I'll just put a couple of accolades on your shoulder. But I was speaking not a couple of weeks, months ago with Martin Kleppmann. For the audience, Martin Kleppmann is the guy started the big deal on data-intensive applications. He wrote the Bible because it's so thick, and he's now quite involved with Local First. And he was a consultant also for the Bluesky Protocol, actually the protocol behind it.

So, in terms of distributed systems, he's one of the guys that actually knows what they're talking. And he was mentioning about one of the libraries, well, actually the library in terms of local-first software that you can build around it, Automerge. And I was like, "Okay, what are you doing?" It's like you have so many different scenarios, and it's impossible to create an SDK for each of them without having a core, and it'll be hard to port it. And he was just very confident, very calm.

And he said, "Well, it's easy. We build Automerge in Rust, and you just compile it as WebAssembly, and then you have so many options in pretty much all the languages and then off you go". And that was quite nice because, as you mentioned, WebAssembly is quite big in the cloud space. I spoke, I think last year, with some of the guys from Scaleway, I think they were working on that at that point.

So, it seems there are two ways in the cloud development space. One of them is to just go with microVMs, and some of the people are going with Firecracker, and that's one of the ways, and the rest of them are going with WebAssembly. And I think another interesting conversation I had was with Max Körbächer. He was one of the guys behind the WebAssembly runtime on Kubernetes.

Andrea Peruffo: SpinKube.

Olimpiu Pop: SpinKube, exactly. And he said, "Okay, if I would like to have something very efficient in the Kubernetes space, you have a couple of loads that you can run them in Kubernetes, and then in the small cracks of the space that you still have in terms of memory and CPU, you can just run a couple of WebAssembly jobs and then you'll have a very efficient way of looking at it". So, it seems that there is a whole ecosystem and there is a lot of symbiosis going on, and that's very nice to see happening.

Andrea Peruffo: There are many different ways to employ WebAssembly nowadays, but something that sounds very familiar to me is what Red Hat said, that they will write Rust and deploy anywhere, which sounds very familiar with what they are doing with OpenFeature and Spotify Confidence. So, those are feature flags, as the case for enabling and disabling flags into your program.

And they need to have the same core logic for the flags to be distributed across a lot of different programming languages, which is Java, Go, native languages, and Swift, and whatever. And the path that they are taking, or they are trying to take, is to add this initial subset of rules written in Rust. And, as the case that just run a WebAssembly runtime into the specific ecosystem. This seems to be very portable and very efficient for both kinds of workloads.

Olimpiu Pop: Well, we definitely covered a lot of things that you can do with WebAssembly. Now, are there any counter applications what people shouldn't do with WebAssembly because it's either too big of a deal or it's something that it'll not be efficient, out of what you know?

Current Limitations of WebAssembly [29:23]

Andrea Peruffo: What we enabled recently with WasmGC is the fact that you can take a Java application, compile it, for example, using WebImage, which is a version of Native Image by GraalVM folks that will emit WebAssembly, and once you have WebAssembly, you can translate it back to Java bytecode and run it on the JVM.

So, despite the fact that this is possible today, is that something that I would encourage people to do? Because each and every step, each and every translation increases a little bit of the number of bindings and the number of embeddings that you need to run the regional program, making it slower. But the fact that this is possible is still very cool.

WebAssembly has a very, very opinionated and good memory model that prevents you from CVEs using a separate tip. And so, in any application where you want to run a piece of software which you are not confident about, or you really don't want to crash your machine around that piece of code, WebAssembly is a perfect fit. For what is not clear there at the moment, for example, it doesn't have any notion of concurrency or parallelism. This is a no-go as of today.

So, if your application needs a lot of performance and those performance are achieved by categories onto your machine, this is not something that WebAssembly alone can give you as of today.

Olimpiu Pop: Okay. So, that means that if you want to do something that you want to have guaranteed single-thread, just drop it in WebAssembly, run it in WebAssembly, and that's guaranteed. Other than that, if you need that, you have to take care of that abstraction yourself. So, probably just break it down, just build it in different WebAssembly, and then you do the orchestration in the programming language that allows doing that.

And actually, come to think about it, this year at QCon there was a guy, and he was talking about this exact thing, and he said that because he wanted to have guaranteed that it's running only on one thread, he just dropped everything in WebAssembly, and that gave him that guarantee in safety and having it in the sandbox. And as pretty much every project that we speak about, I'd like to close talking about the community because obviously you're very involved. How should people come and approach if they want to contribute? And after that, I know that you have an announcement that you would like to make public as well.

Endive Forks Chicory [31:50]

Andrea Peruffo: Yes. Come and talk to us. We have a Zulip channel, but there are also issues and pull requests. So, just open an issue, try to speak with us. It is pretty easy. We welcome contributions from all around. So, just open an issue or say we are trying to use this technology. We will try to do our best to support the use case and get you started having WebAssembly running in your application.

Talking about big announcement, yes, we do have one. There's the fact that we are going to fork Chicory under the Bytecode Alliance organization, and the new name is going to be Endive. We have tried to talk with Dylibso. Unfortunately, we couldn't make a deal for clean transfer of the project keeping the name, but the same maintainers of the old project will be on Endive and will be maintaining the new runtime that we hope to release very, very soon under Bytecode Alliance. This brings together a bunch of very good things.

So, the project gets closer to the community, and we hope to get more individuals and people contributing to the runtime. And this is detached from any specific company. So, we go under a foundation so that everyone would be free to contribute instead of contributing to a single company. And we are going to comply with all the more restrictive rules of Bytecode Alliance that is helping us making the runtime as secure and available as possible of the JVM.

Olimpiu Pop: So, moving on, I have to change the botanical perspective from Chicory to Endive. And I have to give the story because at some point we were discussing, it was like chicory is used in Romania as well, used to be used in Italy as well to make something that seems like coffee that has really shitty taste. Yes, and now we are keeping the botanical one. Thank you, Andrea, for your time. Good luck on the new challenges and to grow the community around Endive.

Andrea Peruffo: Thank you. We hope for the best, but we are pretty sure and confident about this move because all the old community will come along, and we will be able to deliver a lot of value on top of JVM as we are already doing.

Olimpiu Pop: Thank you. Good luck.

Andrea Peruffo: Thank you, Olimpiu.

Mentioned: