5 ms·

Please no, leave that to js. Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuf

by jokoon 8y ago

Please no, leave that to js. Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?

ben-schaaf 8y ago
I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'. I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations. The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.
- megaman22 8y ago
  Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript. Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...
  - kodablah 8y ago
    One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".
    - crooked-v 8y ago
      > sometimes shitty I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
      - megaman22 8y ago
        Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
  - kibibu 8y ago
    Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
    - andyonthewings 8y ago
      Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
      - deleted 8y ago
        [deleted]
      - imtringued 8y ago
        Are those CVEs still active or has google/adobe fixed them already?
        kibibu 8y ago
        They generally only get published in any detail once they've been fixed. Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...
      - sanxiyn 8y ago
        Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
        GenericsMotors 8y ago
        Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
        rthugh02 8y ago
- pjmlp 8y ago
  You can cache runtimes with IndexDB, no need to keep downloading them.
  - vimslayer 8y ago
    But IDB follows the same-origin policy, so you can't share the cached runtime between different apps. At least not unless you can load it from the same public CDN. Edit: Actully, I'm not sure you could do that even with the public CDN.
    - pjmlp 8y ago
      Sure, but you can cache it between invocations of the same app, meaning one can make PWAs with WebAssembly help.
kodablah 8y ago
I disagree, I would like WASM impls to offer one that you can optionally leverage for many reasons. Regardless, here is a recent thread that does a good job discussing pros/cons: https://github.com/WebAssembly/gc/issues/36 https://github.com/WebAssembly/gc/issues/36
CyberShadow 8y ago
> Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level? I believe the big obstacle is that the stack is managed by the VM and isn't accessible directly (at least, in the form of one continuous memory region per thread). A likely constraint that led to this was to allow interoperability with the JavaScript stack.
comex 8y ago
The core issue is that WebAssembly VMs use the host’s native stack for return addresses and local variables, without providing wasm code any way to inspect or manipulate that data. Thus, there’s no way to scan the stack for GC roots, as would be possible in a ‘real’ assembly language. Programs do typically maintain a second, separate, stack, located within wasm-accessible memory, for things like local variables that have their address taken. In theory, you could make the compiler store all locals there across function calls; I think that might be what Go does. But that’s a performance waste. In any case, a manual approach won’t solve the use case of accessing JS/DOM objects from WebAssembly; that requires interoperating with the existing JS garbage collector.
- nerpderp83 8y ago
  If you and I join forces, we can get the stack exposed in WASM2. Or we can run our WASM on WASM and hope the JIT can handle the inner interpreter.
  - kevingadd 8y ago
    The full stack will never be exposed for safety and verification reasons, though it's possible you could get some sort of read-only stack walk primitive... it might be very slow. The wasm stack intentionally does not live in the heap so that it's impossible-ish for exploits to target the stack.
amelius 8y ago
What if a complicated Javascript object is passed to WASM, and a reference stored in a WASM object? How would the GC trace the reference across the language boundary?

by jokoon 8y ago

Please no, leave that to js. Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level?

ben-schaaf 8y ago

I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'. I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations. The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.

megaman22 8y ago
Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript. Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...
- kodablah 8y ago
  One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".
  - crooked-v 8y ago
    > sometimes shitty I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
    - megaman22 8y ago
      Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
- kibibu 8y ago
  Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
  - andyonthewings 8y ago
    Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
    - deleted 8y ago
      [deleted]
    - imtringued 8y ago
      Are those CVEs still active or has google/adobe fixed them already?
      - kibibu 8y ago
        They generally only get published in any detail once they've been fixed. Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...
    - sanxiyn 8y ago
      Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
      - GenericsMotors 8y ago
        Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
      - rthugh02 8y ago
pjmlp 8y ago
You can cache runtimes with IndexDB, no need to keep downloading them.
- vimslayer 8y ago
  But IDB follows the same-origin policy, so you can't share the cached runtime between different apps. At least not unless you can load it from the same public CDN. Edit: Actully, I'm not sure you could do that even with the public CDN.
  - pjmlp 8y ago
    Sure, but you can cache it between invocations of the same app, meaning one can make PWAs with WebAssembly help.

kodablah 8y ago

I disagree, I would like WASM impls to offer one that you can optionally leverage for many reasons. Regardless, here is a recent thread that does a good job discussing pros/cons: https://github.com/WebAssembly/gc/issues/36 https://github.com/WebAssembly/gc/issues/36

CyberShadow 8y ago

> Why can't they just let devs embed their own garbage collector? Isn't he role of an assembly language to let the developer do stuff at a low level? I believe the big obstacle is that the stack is managed by the VM and isn't accessible directly (at least, in the form of one continuous memory region per thread). A likely constraint that led to this was to allow interoperability with the JavaScript stack.

comex 8y ago

The core issue is that WebAssembly VMs use the host’s native stack for return addresses and local variables, without providing wasm code any way to inspect or manipulate that data. Thus, there’s no way to scan the stack for GC roots, as would be possible in a ‘real’ assembly language. Programs do typically maintain a second, separate, stack, located within wasm-accessible memory, for things like local variables that have their address taken. In theory, you could make the compiler store all locals there across function calls; I think that might be what Go does. But that’s a performance waste. In any case, a manual approach won’t solve the use case of accessing JS/DOM objects from WebAssembly; that requires interoperating with the existing JS garbage collector.

nerpderp83 8y ago
If you and I join forces, we can get the stack exposed in WASM2. Or we can run our WASM on WASM and hope the JIT can handle the inner interpreter.
- kevingadd 8y ago
  The full stack will never be exposed for safety and verification reasons, though it's possible you could get some sort of read-only stack walk primitive... it might be very slow. The wasm stack intentionally does not live in the heap so that it's impossible-ish for exploits to target the stack.

amelius 8y ago

What if a complicated Javascript object is passed to WASM, and a reference stored in a WASM object? How would the GC trace the reference across the language boundary?