Comment by mike_hearn | Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Parent Full thread

That would be cool but I wonder how much difference it will make. Most managed languages share at least two attributes:

1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation.

2. You need a JIT for performance.

A good test of whether WASM is really heading towards generality is whether you could implement V8 as https://www.google.com/v8-js.wasm and just auto-include it into HTML pages for backwards compatibility. I know you have unusual experience and expertise in meta-circular VMs - is WASM really heading in this direction? The two obvious sticking points today are: V8 would get downloaded fresh on each origin, and JITd fresh on each page load, and what does such a runtime emit as compiled code?. Is your JITC being JITCd by a JITC and if so is the JITCd output then being JITCd a second time? If so, how on earth does this make sense?

An alternative would be to explore whether the process level sandboxes are now good enough to just allow native code to run inside them and let people use their existing managed language VMs. Google thought that was close to plausible many years ago with NaCL, and kernel sandboxes got a lot stronger since then. It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.

> 1. Large runtimes and std libs.

Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine.

> 2. You need a JIT for performance.

I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there.

Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends.

> It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.

The politics were...complicated. I'd tell my side but it's probably best I don't.

> Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL.

Sadly that wouldn't work with standard libraries that heavily use monomorphized generics, like Rust and C++

Hmm interesting. I thought the cache segmentation was to block timing attacks by the web server (measure time between first page send and js execution to figure out what files are cached i.e. your browser history). I didn't realize it was due to lack of confidence in the JIT. Isn't a WASM JITC a fairly straightforward thing?

Re JVM on wasm with gc: it might be simpler at first to build a Graal/native-image backend for wasm+gc. No runtime JIT needed. Happy to join in on the fun.

I recall NaCL, that also provided a sandbox and had a standalone version next to the web browser integration.

> 1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation.

Right but that's only one, niche use case (why you'd want plugins in a web page ?).

Even if you are web app with plugins

* that is not a problem for first load, user adds plugins later once they get familiar with the app

* you can still (I assume) just download it in the background and shove it into local storage

The whole use case seems to be "there is an app that would benefit from plugins and we don't want someone to learn the language just to write that plugin" and the idea is pretty sound - WASM embeds well and is fast enough.

Reply on news.ycombinator.com