V8 Release v9.6 | Hacker News Reader

V8 Release v9.6

v8.dev

61 pointstosh27 comments

>> The Reference Types proposal, shipped in V8 v9.6, allows using external references from JavaScript opaquely in WebAssembly modules.

This is a major step for WebAssembly which I've waited for a long time! Note that Chrome was the last major browser not supporting reference types, so soon we'll be able to use this on real websites: https://webassembly.org/roadmap/

The main contribution is that now arbitrary values can be passed between JS and Wasm modules. These will show up on the Wasm side as opaque `externref` types.

This allows (arbitrarily powerful) Wasm modules that only import JavaScript glue code instead of having to wrap their exports with JS functions. "Modules that import the functionality they need" is, IMO, a much saner model for creating an ecosystem of modules than "modules which are wrapped with functions specific to the functionality they need". I think this will lead to

* more transparent code (= closer correspondence between the code which is compiled to Wasm and the thing that actually runs in your browser)

* a standard interface between functions across the ecosystem => much more potential to just import and use Wasm modules written in other languages

* an easier way to ship only the minimal amount of JS glue code you need

So it's.... V9 now? . . . I'll get my coat

It is either a more performant engine which will be V12, or more efficient which will be V6.

V12s are also inherently perfectly balanced :)

Along with their i6 counter part but I digress.

yes Cult of V8 is no more...

>> The Reference Types proposal, shipped in V8 v9.6, allows using external references from JavaScript opaquely in WebAssembly modules.

Does this mean we now have direct DOM access from WASM and GC support?

No, not yet. This is just the first step, which allows passing handles to JS/DOM objects to WASM, but they are opaque to WASM and they cannot yet be interacted with in any other way than passing them back to JS.

It just means that the Javascript API shim between WASM and web APIs doesn't need to translate between numeric handles and Javascript object references anymore, making those shims much smaller, and maybe in some cases the shims can disappear completely.

(here's an example of such a shim for WebGPU in the Emscripten SDK: https://github.com/emscripten-core/emscripten/blob/main/src/...)

This is something that I'm worry about: It forces Emscripten builds to be created differently in the way the build artifacts will be compatible only with that version of V8 - in practice it means a dead feature that looks nice, but we can't use for a long long time.

Apparently it's already supported everywhere except Chrome:

https://webassembly.org/roadmap/

So with Chrome's quick release cycles it's probably not too bad (not sure about the 'branded' mobile browsers on Android though).

Thanks for the correction and for the link!

Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback.

My worry is that we end up with fallback cascade: - full featured wasm - wasm - asm.js

I'm aware that's the reality of technology under development - and most likely we will just find a solution for that (like secondary build (or link if it's just link time)).

It's just too bad we can't easy polyfill new features in old browsers for wasm.

Still love WASM <3

>Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback

Well, if that's a pain, then 6% is small enough to drop/force to upgrade.

And eventually WebGL/WebGPU, one step at a time to have full Flash tooling back, and the plugins will be revenged.

https://www.opensilver.net

https://leaningtech.com/cheerpj

https://leaningtech.com/cheerpx-for-flash

Looking forward to it.

I'm waiting for a Rust version, mainly because of its stronger security but also because of the integration.

Edit: Of the JS engine which is now in C++; not sarcasm.

Rust version of what? V8, JS engine?

I think it's sarcasm, but rather hard to tell.

Are they rewriting V8 in rust?

Nope, https://security.googleblog.com/2021/09/an-update-on-memory-...

Ever heard of a little project called Firefox? I hear they've been dipping their toes a little into the space of late.

Even Servo used a JS implementation written in C++ though.

Servo was a rendering engine project. They used an existing JS engine. Very different projects.

V8 compiles JavaScript into machine code, which is then executed. It is an inherently unsafe business to be in, while Rust might make it more safe it will never make it safe. Better to put that effort into better sandboxing, as that is the weakest link.

Just because the Rust code cannot be made "fully" safe doesn't mean it should be ruled out and replaced with sandboxing. For one, they can both be worked on, but it's also important to note that Rust can provide useful safety guarantees that are actually useful to have. For example, in C++ a linear overflow may end up leading to the ability to spray arbitrary shellcode, but in Rust you may be able to guarantee that any out-of-bounds accesses cannot be used to do this.

It would be so nice to have something like -fsafe instead of a myriad of mitigations, where the right defaults get enabled, but it will never happen.

By the way, the upcoming ARM conference has sessions regarding MTE.

You can keep waiting, given that Google prefers to somehow mitigate C++ flaws than going through Chrome's version of Servo.

https://security.googleblog.com/2021/09/an-update-on-memory-...

> Even if we started writing new large components in Rust tomorrow, we’d be unlikely to eliminate a significant proportion of security vulnerabilities for many years. And can we make the language boundary clean enough that we can write parts of existing components in Rust? We don’t know yet. We’ve started to land limited, non-user-facing Rust experiments in the Chromium source code tree, but we’re not yet using it in production versions of Chrome - we remain in an experimental phase.

>Of the JS engine which is now in C++; not sarcasm.

Not gonna happen.

Reply on news.ycombinator.com