Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly architecture for Go

docs.google.com

Post reply on HN
Print view View original

21–30 of 71 posts

Re: WebAssembly architecture for Go

#21

Post by pcwalton »

The main benefit of using the Web Assembly GC is not improved performance within the language, but rather having a single GC that handles both native DOM objects and language objects. Having two GCs interoperate is a big pain, and it's very difficult to pull off without leaks or performance problems. This is especially true for DOM objects, which have no user-visible finalizers. (The closest thing is WeakMaps, but I don't believe these are enough to implement proper cross-language GC, because you can't query whether an potentially-dead object is actually dead.)

Web Assembly GC is not a performance optimization; it's necessary for correctness.

Re: WebAssembly architecture for Go

#23

Post by ramenmeal »

kodablah wrote: post #20

> Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs I don't think it's hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can't (yet) do. > Most file system operations are ma…

> WASM has fairly strict stack/frame rules/types, so arbitrary gotos wouldn't work.

kinda funny because golang follows the same idea.

Re: WebAssembly architecture for Go

#24

Post by mlevental »

kodablah wrote: post #20

> Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs I don't think it's hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can't (yet) do. > Most file system operations are ma…

>non-JS WASM backend

...what's a non-js wasm backend?

Re: WebAssembly architecture for Go

#25

Post by sctb »

guessmyname wrote: post #18
tbodt wrote: post #8

If you tried to look at the document and found that the entire internet has been screwing with the formatting, change "Suggesting" to "Viewing" in the top right. Seems like someone forgot to check permissions on the document.

Here is a direct link [1] for easy access; maybe Dang can change the link. [1] https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0...

Thanks! We updated the link from https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0....

Re: WebAssembly architecture for Go

#26

Post by sitkack »

goalieca wrote: post #7
johnhenry wrote: post #2

I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?

Follow-up question, why can't LLVM -> Web Assembly solve the problem?

x86 elf -> wasm could solve this problem.

Re: WebAssembly architecture for Go

#27

Post by slimsag »

mlevental wrote: post #24
kodablah wrote: post #20

> Go’s garbage collection is fully supported. WebAssembly is planning to add its own garbage collection, but it is hard to imagine that it would yield a better performance than Go’s own GC which is specifically tailored to Go’s needs I don't think it's hard to imagine reading the GC proposal. The JS collector that might be reused could be off thread, something WASM can't (yet) do. > Most file system operations are ma…

>non-JS WASM backend ...what's a non-js wasm backend?

WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).

Re: WebAssembly architecture for Go

#28

Post by sseth »

pcwalton wrote: post #21

The main benefit of using the Web Assembly GC is not improved performance within the language, but rather having a single GC that handles both native DOM objects and language objects. Having two GCs interoperate is a big pain, and it's very difficult to pull off without leaks or performance problems. This is especially true for DOM objects, which have no user-visible finalizers. (The closest thing is WeakMaps, but I…

In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.

Re: WebAssembly architecture for Go

#29

Post by tudelo »

slimsag wrote: post #27
mlevental wrote: post #24

Earlier quoted context omitted.

>non-JS WASM backend ...what's a non-js wasm backend?

WebAssembly can be used anywhere. It is not tied to JavaScript in nature. So think of it kind of like the JVM in a way (but it's not an implementation, just a spec).

So people are using wasm in a non web context ?

Re: WebAssembly architecture for Go

#30

Post by slimsag »

sseth wrote: post #28
pcwalton wrote: post #21

The main benefit of using the Web Assembly GC is not improved performance within the language, but rather having a single GC that handles both native DOM objects and language objects. Having two GCs interoperate is a big pain, and it's very difficult to pull off without leaks or performance problems. This is especially true for DOM objects, which have no user-visible finalizers. (The closest thing is WeakMaps, but I…

In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.

It's also worth mentioning WASM has no GC today.
Post reply on HN