3 ms·

I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can alre

I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can already be implemented in pure WASM (without the new GC support), just more or less awkwardly. As for "just another ISA", there have been CPUs which had separate call- and data-stacks, with the call-stack living on the CPU and not directly accessible to code. In that sense WASM isn't much different then those esoteric CPUs, yet those also implemented "just another ISA". And even though WASM might not allow free control flow, I yet have to see a noticeable performance difference between WASM and native for this type of "worst case code": https://github.com/floooh/chips/blob/f5b6684ff6e899429544b2133b31d912ebc15f40/chips/z80.h#L1815-L1849 https://github.com/floooh/chips/blob/f5b6684ff6e899429544b21...

3cats-in-a-coat 3y ago
We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.
chriswarbo 3y ago
> Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.

3cats-in-a-coat 3y ago

We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.

chriswarbo 3y ago

> Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.