You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assuming opaque GC references make it through... #733
It would be very useful to have these references passed between WASM threads or Web Workers. Even if they aren't accessible in those context. This puts some more constraints on the GC but not as bad as if they're completely accessible. Applications can defer to the main thread for reads and mutations.
In this environment it would be good to avoid locks on immutable cells such as frozen properties in JS objects or if there is a new GC object model. In this model, only reads would need a special op.
This would allow us to implement a similar strategy as https://ocaml.io/w/Multicore for parallelism that favors immutability.
The text was updated successfully, but these errors were encountered:
@sebmarkbage Could you give some thought to how ocaml could support global GC in distributed systems, and then perhaps the solutions would translate to global GC between wasm instances where these were implemented within the linear memory?
I can't see such a well tuned GC getting good support across all the web browsers, but if you could implement this within the wasm linear memory then there might be more opportunities, and are locks all that is lacking?
Implementing this in linear memory is fine but interaction with JavaScript GC is going to be critical for the foreseeable future IMO. Lots of critical DOM APIs (even if you target WebGL) are still difficult to integrate with, without an integrated GC. Especially with the lack of weak references in JavaScript. There is also lots of legacy code that needs to be supported in many apps and integrating with it is critical.
I fear that with a distributed system there will be too much copying to linear memory, in an already memory constrained environment (mobile). The lack of weak references in JavaScript prohibits good distributed GC. Arguably that's a primitive that could be added but doesn't alleviate the primary concern.
Assuming opaque GC references make it through... #733
It would be very useful to have these references passed between WASM threads or Web Workers. Even if they aren't accessible in those context. This puts some more constraints on the GC but not as bad as if they're completely accessible. Applications can defer to the main thread for reads and mutations.
In this environment it would be good to avoid locks on immutable cells such as frozen properties in JS objects or if there is a new GC object model. In this model, only reads would need a special op.
This would allow us to implement a similar strategy as https://ocaml.io/w/Multicore for parallelism that favors immutability.
The text was updated successfully, but these errors were encountered: