that's of no use to me. I want all objects to be WASM objects and yet be GCable.
-
-
I need some likbez. Would _love_ an article talking about best possible GC within today's WASM limits and explanation where it falls short.
4 replies 0 retweets 1 like -
My opinion is that you can forget about GC in WASM unless you implement something like Andreas Rossberg's proposal.
1 reply 0 retweets 1 like -
I've heard that a lot, but curious about the details. I can imagine a perfectly functional GC but my understanding of GC is severely limited
1 reply 0 retweets 0 likes -
if you want to see how interactions with DOM look like when there is no GC awareness look at Dart-JS FFI design from Dart 0.x. Nobody liked that. NOBODY.
1 reply 0 retweets 0 likes -
I don't think language runtime designers should be concerned about DOM access. That's a framework concern, and largely a solved issue.
6 replies 0 retweets 0 likes -
This makes no sense to me. Interfacing to the DOM is all about GC. That's why we put a C++ tracing GC in Blink.
2 replies 0 retweets 0 likes -
But the general idea is that application code never holds pointers to DOM nodes, so there's nothing to trace.
1 reply 0 retweets 0 likes -
I *think* that y'all have different usecases, and GC isn't useful for yours. It's definitely useful for what Slava and Erik have in mind.
1 reply 0 retweets 0 likes -
I think GC is useful for Yegor's use case too, it's just a very restricted use case. I am in uncertain how much it all scales beyond simples cases when application code is mixed in
1 reply 0 retweets 0 likes
Already excited about wasm/js/DOM graphs that are mostly traced, contain bits of ref counting, and rely on phantom handles and finalizers :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.