Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

... We've really reinvented the JVM. Not sure that's bad; hope we can do better this time.

I like to think of it more that Javascript/WebASM will finally accomplish what Java spent decades trying to do: be the completely ubiquitous hardware-independent code platform.

Javascript has truly become the "Write Once, Run Anywhere" language.

https://www.destroyallsoftware.com/talks/the-birth-and-death... (2014)

Spectre came along and ruined the awesome conclusion of that talk.

The idea was that the cost of using WASM would be entirely offset by the speedup of removing the cost of hardware memory protection. We could do that if everything ran in one big VM because the VM would enforce the memory protection.

Unfortunately, now we can't rely on a VM for memory protection anymore. We have to assume that any code running in the same address space can access any memory in the same address space.

So we need the hardware memory protection after all. You can say goodbye to your WASM-only future.

I assume that new chips will address this vulnerability, correct? Couldn't the VM detect whether the hardware is secure and decide whether to use hardware memory protection or not?

At this point it seems practically impossible to deal with completely.

V8 at least have given up on the concept of trying to protect memory within the same address space.

https://v8.dev/blog/spectre

> new chips will address [these vulnerabilities]

It doesn't seem likely. The chipmakers will fix the vulnerabilities that break isolation between processes and between user-kernel, but the within-process issues will probably stick around.

Well, Spectre is a largely-theoretical class of vulnerabilities, that doesn't even apply to chips that don't do speculation in hardware, and that is purely about information disclosure via side-channel mechanisms. It might be a bit of a concern for some users, but it's not the end of the world - for instance, the designers of the Mill architecture have a whole talk discussing how Spectre as such doesn't really apply given the architectural choices they make. And if running stuff in different address spaces is enough to mitigate it effectively, that still provides quite a bit of efficiency compared to an entirely conventional OS.

> doesn't even apply to chips that don't do speculation in hardware

This is an interesting way to put it. I would have said "applies to pretty much every CPU manufactured in the last decades." Your statement would make sense if speculation in hardware was some niche thing, but I think you would be hard-pressed to find an invulnerable CPU that is used in situations where people care about both performance and security.

That's great for the mill, but isn't relevant to the world outside of mill computing.

Nitpick re "chips that don't do speculation in hardware" - load forwarding and speculative cache prefetching and branch prediction are done even by lots of current (and past) processors that don't do speculative execution and hence are considered "in-order" microarchitectures.

This is part of why I want to make a custom OS where each WebAssembly process can be in its own hardware protected memory space. I'm looking at building on top of seL4.

I basically want to do this _without_ javascript though. My implementation is in Go: https://github.com/Xe/olin

How do you figure, when certain features of javascript are supported on some browsers and not others? You've just swapped OS dependence for runtime dependence. JS's solution to this problem? Another layer of abstraction to make the JS cross-browser.

WASM already has this problem, what with 5 or 6 different incompatible runtimes already in existence.

You just use the lowest common denominator, depending on your definition if “everywhere”. When in need use shims.

It’s not literally “run anywhere” it’s “for all intents and purposes run anywhere”.

One important difference is that GC isn't baked in, so in a way Wasm is actually lower-level than the JVM.

An optional GC is being added: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

(Emphasis on optional)

Yep, so that way you have the option of one or the other

Would it be reasonable to see a WebAssembly VM that is implemented in silicon? Perhaps on an FPGA as a first step?

No idea, although it might defeat the purpose a bit (which doesn't mean nobody would do it)

This was already done for the JVM. It was an utter failure, and not economically viable at all.

As the OP said: this is reinventing the JVM, just worse. Including making all the mistakes again.

(At least for the server, that is. I see a great future for WebAssembly on client systems, where the JVM can be considered a failure.)

Maybe, however remember that you then need to buy new hardware to use new WASM features.

Also WASM isn't really ideal for interpretation, this could make implementing the CPU harder (however I have no clue about implementing CPUs, so this is just a guess).

What would be the advantage? Performance? Probably not much after JIT compiling WASM to native machine instructions. If there is an actual problem there, I guess it would be better to just add new native instructions that support WASM semantics. The JIT can then use these instructions if available.

Right now WASM can't do much without a runtime, so I think a WASM-only CPU is probably infeasible for some time.

It would be hard because traditionally most of our hardware relies on the register memory model. Implementing a hardware stack can be done but there are very few silicon CPUs like that thus a lot of the research which has been done on getting register machines up to speed in terms of caching and speculation could be difficult. Then there is the fact that webassembly doesn't use branch labels rather it uses blocks, which AFAIK have never actually been used on traditional CPU hardware.

People have tried to create high level language CPUs but often failed in terms of performance. An overview can be found here: https://en.wikipedia.org/wiki/High-level_language_computer_a...

When is ETA of JVM value type again? WebAssembly already got it.

As does the CLR, TIMI, PNaCL, Apple's bitcode variant of LLVM.

And the long forgotten SWF, P-Code, M-Code, UNCOL, ANDF, Xerox bytecode.

No gc.

Practically this is a blessing and a curse. I really wish there was a better story for GC'd apps on WebAssembly because a GC is super expensive at the moment.

Reply on news.ycombinator.com