Hacker News Reader

Comment by dmitriid | Hacker News Reader

Ok, now we need GC and DOM interop. Because reinventing layouts is pain.

Cheerp is our solution to emit mixed mode WebAssembly/JavaScript from the same C++ codebase. It generates bridges to JS code transparently to work around the interoperability limitations of WebAssembly. https://github.com/leaningtech/cheerp-meta/wiki/Cheerp-Tutor...

In order to port other languages (Haskell, Go, Python) to target WASM, we definitely need the possibility of writing a GC in WASM. But to build an efficient GC, we need multithreading and synchronization/memory barrier primitives.

Seems to be on the roadmap:

http://webassembly.org/docs/future-features/

Good to see. By the way, we also need multithreading and shared memory to efficiently support structurally shared immutable data structures across multiple cores.

Shared memory is part of the threading tracking issue.

You can already compile your language's runtime to wasm; this includes the GC. The downsides is that now you're adding all that to your binary size.

"GC support" means being able to integrate with JS's GC, basically, so that your language's wasm runtime could use it instead of your own, saving bytes.

> The downsides is that now you're adding all that to your binary size.

The GHC runtime (that is huge) isn't much larger than a web font. It is not much out the range of the JS libraries out there.

Saving bytes and improving interop, I imagine.

Multi threading brings in all kinds of security issues

But without multithreading, you can use 1/4th or 1/8th of the computation power available on your average consumer device.

What kind of issues are you thinking about? Multithreading is not easy but your typical race conditions and multi threaded problems aren't really opening doors to any new security exploits.

Browsers and WASM have quite decent sandboxing to mitigate security issues. There's WebWorkers already which brings a limited form of threads to the browser.

I'm not seeing a problem with multiple threads in a browser.

What kinds of security issues? I really can't think of any besides some issues with too many threads spawned (that can be trivially blocked).

Could be a new source of undefined behavior and memory exploits, if threaded code is allowed to access collections that allocate memory without taking all the locks they should?

Inside the VM, yes. But not a security threat for the host.

The VM should be sandboxing the pages from each other, so those are potential security threats against targets on the same pages only. Not something to be too concerned about.

Help me understand: What's the difference between that and process separation?

even in the very sandboxed context of WebAssembly?

IIRC you can do GC within WebAssembly (though it's less nice and awkward as I've been told).

But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)

It doesn't sound like that will be possible. DOM interop is baked into the Garbage Collection task[0]. It sounds like there's a dependency there, somewhere.

[0]: https://github.com/WebAssembly/design/issues/1079

edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/

Historically, people have thought that the GC and DOM stuff is intertwined, but the latest DOM proposal doesn't require the GC proposal.

Do you have a link to the separated proposals? It certainly seems entwined on the official roadmap.

https://github.com/WebAssembly/host-bindings/

Awesome. Thanks!

> Because reinventing layouts is pain.

You could simply compile (relevant parts of) Firefox or Chromium to WASM :)

I wished 'lol' was an appropriate response on hacker nws

Reply on news.ycombinator.com