-
Notifications
You must be signed in to change notification settings - Fork 694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opaque GC References in Workers + Lock-free Reads? #985
Comments
@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. |
@rossberg-chromium could you make sure this discussed as part of the GC proposal? |
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: