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

Don't allow IndexedDB serialization of WebAssembly.Module #821

Closed
binji opened this issue Jun 13, 2018 · 3 comments
Closed

Don't allow IndexedDB serialization of WebAssembly.Module #821

binji opened this issue Jun 13, 2018 · 3 comments

Comments

@binji
Copy link
Member

binji commented Jun 13, 2018

We discussed this in the June 12th CG meeting.

IndexedDB serialization of WebAssembly modules is implemented in some browsers, but not all, and code caching is currently only implemented in Firefox (AIUI). It's not clear that explicit caching via IDB provides the best solution. Some implementations will have compiled code using the baseline compiler, but not tiered up. Others will not have compiled any code at all.

In addition, some implementations will not be able to share the cache between origins with IDB, so the HTTP cache will be required instead. This can be made explicit using the cache API, which is a service-worker spec feature but is designed to be available everywhere.

Since the module will already be cached in the HTTP cache, this means explicit caching w/ IDB will have the module stored twice without de-duping magic.

For these reasons, it has been suggested that we remove the currently proposed support for module serialization to IDB. We still want to serialize modules for postMessage, however.

Thoughts/concerns?

cc @lukewagner @titzer @dschuff

@binji
Copy link
Member Author

binji commented Jun 13, 2018

It seems @littledan has already updated #711 to reflect this.

@lukewagner
Copy link
Member

Thanks for capturing this @binji . While this does mean more of a wait before reliable wasm caching of machine code, we've found that streaming+tiering reduces the criticality of caching and so it seems better to do things the Right Way (implementing things we wanted to do anyway).

@binji
Copy link
Member Author

binji commented Jul 18, 2018

This was further discussed on #711, and merged. Closing.

@binji binji closed this as completed Jul 18, 2018
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