1879123 - Experiment omitting response when it matches consumer-cached cacheEntryId

Status: ASSIGNED

(Core :: JavaScript Engine, task, P3)

Description

[Tooru Fujisawa [:arai]]

Given JS source needs to be validated for each request, the on-memory cache should ask necko whether the cache is up to date for each time.

It can be done by following:

• associating a "content ID" to the cache
• the content ID gets updated for each time the cache gets updated
• the content ID is included in the response from necko
• on ScriptLoader side, cache Stencil with the content ID
• for subsequent request to necko, include the consumer-cached content ID
• on necko side, when the consumer-cached content ID is same as the response's content ID, set a flag, and omit the response body
• on ScriptLoader side, if the flag is set, use the cached Stencil, otherwise update the cache

This ensures the validity of the cache, while reducing the IPC cost.

Comment 1

[Tooru Fujisawa [:arai]]

Attachment: WIP: Bug 1879123 - WIP: Prototype cache content ID and on-memory stencil cache for regular script.

Associate "content ID" to each cache.

Response from necko contains content ID, and consumer can cache the response
in its process.

A request for necko can have "consumer-cached content ID", to let necko know
the consumer has cached data from the previous response, and don't need the
file body if the next response has the same content ID.

ScriptLoader uses the content ID to cache the stencil, and use cached stencil
when consumer-cached content ID matches the next content ID.

This reduces the IPC cost for the script source, and also reduces the need for
bytecode cache.

Comment 2

[Tooru Fujisawa [:arai]]

So, the "ID" part is already achieved by cacheEntryId, once bug 1998926 is fixed.
The remaining part is to omit the response body in the IPC when the ID matches.

Comment 3

[Tooru Fujisawa [:arai]]

One thing we should make sure with this optimization is that,
given this happens asynchronous, the in-memory cache entry can be evicted individually or batch cleared before receiving the response.
In that case, the response with the content being omitted cannot be used.

The bug 1998925 patch's dirty flag queries the cache twice, once before the request, and once after the response received.
If the cache gets removed before the response, the dirty flag logic is simply ignored and the response is used.

So, for this bug, we need either:

• (a) When using this "omit response if no change", the cache entry should be kept, even for the explicit clear
• (b) When the cache entry is missing at the point of the empty "no change" response is received, trigger the request again

but (b) will break the spec if the request goes to the server again.
So the (a) would be the most reasonable path.