Skip to content
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

Open
sebmarkbage opened this issue Feb 13, 2017 · 3 comments
Open

Opaque GC References in Workers + Lock-free Reads? #985

sebmarkbage opened this issue Feb 13, 2017 · 3 comments

Comments

@sebmarkbage
Copy link

sebmarkbage commented Feb 13, 2017

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.

@ghost
Copy link

ghost commented Feb 13, 2017

@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?

@sebmarkbage
Copy link
Author

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.

@jfbastien
Copy link
Member

@rossberg-chromium could you make sure this discussed as part of the GC proposal?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants