Re: [w3ctag/design-reviews] WebAssembly Response API / Web Embedding (#167)

> Service workers allow a mechanism to intercede and rewrite streams as downloaded, while still keeping them URL bound. URLs streamed and rewritten by a service worker can be cached until either the URL changes or the service worker that did the rewriting. This seems nice in that it works the same for other resources too (imagine an image format converter).

If a service work can rewrite the wasm binary then the web browser can not control the caching. It can not know what inputs the product (the rewritten stream) depends. It might know that if the up stream source changes that the rewritten output has potentially changed, but it can not know that the rewritten output has not change so can not cache the downstream products of that rewrite using upstream stream URLs and versions alone rather it would be forced to use the rewritten stream as a key and given that these could be large blobs that approach is a far greater burden.

It appears a requirement of effective caching that the rewriting depends on inputs that can be used as effective cache keys, and on those alone. Note that the key might be a provenance trail, for example the input to the compiler might be the key (source URL A version abc, rewritten with source URL B version abc and constants i, j and k). The means that the code that does the rewriting needs to be isolated from other inputs and for any inputs to be well defined (there is a little more to it), and for the web browser to be able to depend on this the web browser needs to isolate such code. The current architecture and framework is not going to work.

By a 'build manifest' is meant something like a Makefile that specifies the source inputs to the data flow such as a URL, and the stages of rewriting along the data flow path. The web browser can then schedule the work and effectively cache the intermediate products or the compiled code as it chooses, and it can re-run these as needed to regenerate code.

We don't need to speculate about what future feature detection is needed, we know what is required to efficiently implement caching with rewriting in general and should design for that now.

We can test proposals using existing web browser support. For example, can wasm be rewritten to asm.js and can caching work effectively. Can the compiled asm.js code be cached using the wasm source URL and version plus the source and version of the code that does the rewriting alone. Can the web browser choose to flush this cache and re-run the pipeline as needed. Can this cached computation be shared safely across origins. These are some tests by which a proposal can be evaluated now, and the proposals being submitted here do not meet these tests.

There are other resource scheduling issues too, for example the wasm code might need a large linear block of memory for its linear memory and it would be more efficient to allocate that after compilation. Compiling on multiple threads can consume a lot of memory, and pre-allocating the linear memory can mean that code will just not run on low memory devices.

Some of the inputs to the pipeline might also be implementation specific matters, and might even be speculative requiring the web browser to re-run the pipeline in on a miss.

If this architecture were addressed well now then it would create an efficient framework for future improvement and it would support some variation between web browsers and thus some experimentation and that seems much more healthy for the web, so this seems very important to get right.

Another test might be: can I promote an alternative web browser that uses a wasm variant with some different performance characteristics and that consumes a different upstream binary encoding, but that can also rewrite to wasm with only a small overhead. An effective pipeline is needed to make that practical.

We still do not have high performance AOT compilers, or better is quite likely, and they many well be able to consumer alternative encodings with a smaller and faster compiler.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/167#issuecomment-303263471