Closed Bug 1523749 Opened 6 years ago Closed 3 years ago

Allow using bytecode directly from XDR buffers

Categories

(Core :: JavaScript Engine, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
Tracking Status
firefox67 --- wontfix

People

(Reporter: tcampbell, Assigned: arai)

References

(Blocks 2 open bugs)

Details

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.

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

(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.

(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.

Blocks: 1458339
Depends on: 1562272
Priority: P1 → P2
Assignee: tcampbell → nicolas.b.pierron
Blocks: 1663955

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.

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)

Assignee: nicolas.b.pierron → arai.unmht
Status: NEW → ASSIGNED

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

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

Depends on: 1710987

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

Blocks: 1662149
No longer blocks: 1662149
Depends on: 1732168
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.