3 ms·

A number of concerns with the viability of the current WASM GC are covered here (Google translation to English): https://habr-com.translate.goog/ru/articles/75

A number of concerns with the viability of the current WASM GC are covered here (Google translation to English): https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl... and the original article: https://habr.com/ru/articles/757182/ https://habr.com/ru/articles/757182/ This is from the author of TeaVM, who has 10 years of experience getting Java and JVM code to run efficiently in the browser. https://teavm.org/ https://teavm.org/ TeaVM's existing transpilation of Java to JavaScript performs well (using the browsers JS GC). It will be interesting to see if WASM GC matures to the point where it is even faster.

azakai 3y ago
Interesting article, thanks! Notes on the issues mentioned there: * The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions). * Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md https://github.com/WebAssembly/exception-handling/blob/main/... * Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example). * Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061 https://github.com/WebAssembly/binaryen/pull/6061 * The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet. * Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority. The author is right that stack walking, signals, and memory control are important areas that could help here. Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.

azakai 3y ago

Interesting article, thanks! Notes on the issues mentioned there: * The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions). * Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md https://github.com/WebAssembly/exception-handling/blob/main/... * Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example). * Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061 https://github.com/WebAssembly/binaryen/pull/6061 * The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet. * Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority. The author is right that stack walking, signals, and memory control are important areas that could help here. Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.