1523749 - Allow using bytecode directly from XDR buffers

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P2)

Description

[Ted Campbell [:tcampbell]]

The preload-cache is shared between content processes and is loading using mmap. This cache contains bytecode data in the XDR which we can try to leverage instead of creating SharedScriptData objects in private memory.

Comment 1

[Ted Campbell [:tcampbell]]

TODO:

• Measure estimated wins
• Assess how best to handle GCPtrAtom no longer being shareable
• Add 'pinned' mode for SharedScriptData refcount
• Add endian checks for XDR buffer
• Emit SharedScriptData header data in XDR stream
• Propagate a 'pinned' flag to XDR decode requests
• Refactor the preload-cache AutoMemMap member to more clearly outlive the JSRuntime

Comment 2

[Ted Campbell [:tcampbell]]

(In reply to Ted Campbell [:tcampbell] from comment #1)

• Assess how best to handle GCPtrAtom no longer being shareable

I tried to measure how much of a regression it would be to move the SharedScriptData::atoms() array to PrivateScriptData(). In an empty about:blank content process it looks like about about 50kB right now. For main process it seems to be a 1 MB regression (this probably uses script cloning the most). For normal web content processes with pages loaded, I see about 60-900kB. Since this is currently a Runtime-level cache, we will lose some of its benefit anyways as Fission is enabled.

We can consider adding a new level of sharing between PrivateScriptData and SharedScriptData for things like atom pointers. In this case, it may be possible to merge atom sets so we share atom pointers for dissimilar scripts.

I don't think this is an insurmountable blocker considering the gains of sharing bytecode across processes.

Comment 3

[Ted Campbell [:tcampbell]]

(In reply to Ted Campbell [:tcampbell] from comment #1)

• Measure estimated wins

Looking at estimates for cache-loaded script data, I'm seeing much lower amounts of shared script data than I was expecting. For an empty content process, I see about 70kB from cache of 320kB total. This rest is probably due to self hosting. The main process itself seems to save nearly 10MB.

As more data is moved from PrivateScriptData to SharedScriptData (Bug 1471062), there should be more wins too. Some further tweaking is probably needed to get more wins here.

Comment 4

[Ted Campbell [:tcampbell]]

Note that we since renamed RuntimeScriptData to [SharedImmutableScriptData](https://searchfox.org/mozilla-central/rev/1a973762afcbc5066f73f1508b0c846872fe3952/js/src/vm/SharedStencil.h#487). This points to the ImmutableScriptData which is fully immutable.

Comment 5

[Tooru Fujisawa [:arai]]

Tested directly using ImmutableScriptData from XDR buffer, for ScriptPreloader,
and run testing/awsy/awsy/test_base_memory_usage.py.

with WIP patch, Base Content JS is reduced by 3.4% (2370kB => 2289kB, -81kB).
the testcase opens 8 about:blank tabs, so there would be 8 processes for them, and 3 preallocated, and extensions, network, and parent.

will check other tests as well.
(I'm looking for a testcase that has many iframes and uses many processes with fission)

Comment 6

[Tooru Fujisawa [:arai]]

latest patch, with applying it to self-hosted JS, instead of ScriptPreloader
https://treeherder.mozilla.org/jobs?repo=try&revision=21201fec790a196abbefc69ed949dd5e221cb50a

Comment 7

[Tooru Fujisawa [:arai]]

that results in -184kB for Base Content JS.
and we'll get another reduction for ScriptPreloader usage, in comment #5.

Comment 8

[Tooru Fujisawa [:arai]]

Filed bug 1710987 for self-hosted JS usage.
will file another bug for ScriptPreloader usage.