use alt data to cache wasm code compiled from Response

NEW
Assigned to
(NeedInfo from)

Status

()

5 months ago
a month ago

People

(Reporter: luke, Assigned: luke, NeedInfo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 months ago
Since WebAssembly.{compileStreaming,instantiateStreaming} both take a Response, we have a link back to the original cache entry, so we can use the alt-data API (currently used by the JS bytecode cache) to cache machine code.  Later with wasm-esm integration (https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration), we could additionally plug in via the nsScriptLoader.

This is intended to subsume the explicit IDB caching which was recently removed from the wasm spec (bug 1469395) and beat the implicit asm.js caching we do in dom/asmjscache.  The core (de)serialization machinery is still present (and actively used by asm.js caching).

The existing wasm streaming support this would build on is FetchUtil::StreamResponseToJS:
  https://searchfox.org/mozilla-central/source/dom/fetch/FetchUtil.cpp#530
and the alt-data interface we need to use is nsICacheInfoChannel, which lets us get a stream for the serialized module.

It looks like we'll need some modest changes to the alt-data API: bug 1487100.  In the meantime, we can get something sorta-working by unconditionally setting the preferred alt-data-type "wasm" in fetch().

When alt-data is implemented for the DOM Cache API (bug 1336199), this same support should Just Work for DOM Cache / ServiceWorker which would perhaps provide access to larger quota and lower churn.
(Assignee)

Updated

5 months ago
Depends on: 1487475
(Assignee)

Updated

5 months ago
Depends on: 1330661
(Assignee)

Updated

3 months ago
Depends on: 1500203
(Assignee)

Comment 1

2 months ago
Created attachment 9025507 [details] [diff] [review]
request-alt-data-for-wasm (test)

Ok, so I finally started to play around with the awesome new functionality added by bug 1487100.

Valentin: this tiny patch requests alt-data for "application/wasm", which I would expect to attach an nsICacheInfoChannel to the InternalRequest.  The fprintf() before AsyncOpen2() shows I'm calling PreferAlternativeDataType() for the fetch() in question, but the fprintf() on the consuming end indicates there is not an nsICacheInfoChannel.

I fully expect I'm doing something silly or expecting to find the nsICacheInfoChannel in the wrong place.  Can you see anything wrong?

I'm using https://lukewagner.github.io/wasm-mime-type to test this path.
Assignee: nobody → luke
Flags: needinfo?(valentin.gosu)
I think Nicolas can help here.
Flags: needinfo?(valentin.gosu) → needinfo?(nicolas.b.pierron)
Comment on attachment 9025507 [details] [diff] [review]
request-alt-data-for-wasm (test)

Review of attachment 9025507 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/fetch/FetchDriver.cpp
@@ +755,5 @@
>    } else {
> +    nsCOMPtr<nsICacheInfoChannel> cic = do_QueryInterface(chan);
> +    if (cic) {
> +      fprintf(stderr, "### PREFERRING for %s !\n", url.get());
> +      cic->PreferAlternativeDataType(NS_LITERAL_CSTRING("wasm"), NS_LITERAL_CSTRING("application/wasm"));

I do not know much of this code base, but …

My guess would be that you have to create an AlternativeDataStreamListener (as done as few lines above) and set the mAltDataListener field in order to pipe the input stream of the nsICacheInfoChannel through the fetch API.
Forwarding the need-info to Ben Kelly as he reviewed this implementation and might know better where to patch the default case for setting the preferred alternated data type.
Flags: needinfo?(nicolas.b.pierron) → needinfo?(ben)
Just heard that Ben left Mozilla, so based on Nathan feedback, I will re-forward to Andrew / Andrea.
Flags: needinfo?(bugmail)
Flags: needinfo?(ben)
Flags: needinfo?(amarchesini)
I think Eden is working on the alternate stream support in Cache API and may also have input here.
Yes, I'm going to redirect to Eden for his expertise here.
Flags: needinfo?(bugmail) → needinfo?(echuang)
Flags: needinfo?(amarchesini)
(Assignee)

Comment 8

2 months ago
Learning a bit more, I see I was misunderstanding how this was supposed to work.
Flags: needinfo?(echuang)
(Assignee)

Comment 9

a month ago
To summarize, given an InternalResponse, it's not currently possible to write the alt-data output stream because there is no way to get the nsICacheInfoChannel (if there is one).

Discussing options with baku at the all-hands:
 - One option would be to set InternalResponse::mCacheInfoChannel not just when the alt-data cache entry *already* exists, but also when the content-type specified by preferAlternativeDataTypes() matches, so that alt-data can be written.
 - Another option would be to change the nsIInputStream body produced by fetch() so that one could QI it to something providing the nsICacheInfoChannel.  (Maybe this allows killing InternalResponse::mCacheInfoChannel altogether?)
Flags: needinfo?(amarchesini)
You need to log in before you can comment on or make changes to this bug.