1669718 - Introduce initial-specific struct to reduce delazification size

Status: RESOLVED FIXED

(Core :: JavaScript Engine, task, P1)

Description

[Tooru Fujisawa [:arai]]

some stencil fields aren't used in delazifiaction.
we can use smaller struct for delazification, so that:

• reduces memory consumption when we keep stencil as a cache
• reduces XDR data size
• simpler delazification code (all fields are used)

Comment 1

[Tooru Fujisawa [:arai]]

there will be common stencil fields between initial and delazification, that's for GC things (regexp, bigint, object, scope).
and different fields are script vs update.
we can create GC things class and make Parser/BytecodeEmitter hold a reference to it, so that the difference needs be handled only for script.

Comment 2

[Tooru Fujisawa [:arai]]

WIP patches: https://treeherder.mozilla.org/#/jobs?repo=try&revision=80bae93e2110c968edf49858d30a8f3f5a6f3899

sizeof(js::frontend::CompilationInfo) = 600
sizeof(js::frontend::DelazificationInfo) = 400

sizeof(js::frontend::ScriptStencil) = 120
sizeof(js::frontend::DelazificationScriptStencil) = 80
sizeof(js::frontend::DelazificationInnerScriptStencil) = 56

will check XDR size

Comment 3

[Tooru Fujisawa [:arai]]

After opening Reddit from new tab page and restart and reload, I see the following encoding result.

chunks = the number of initial + delazification
bytes = the size of XDR encoded buffer

(only listing results with same number of chunks. there are some more, but with different chunks = different number of delazification until finish incremental encoding)

https://tpc.googlesyndication.com/sodar/sodar2.js:1:0
  before: 64 chunks (62574 bytes)
  after: 64 chunks (59275 bytes) : 5% smaller
https://www.googletagservices.com/tag/js/gpt.js:1:0
  before: 187 chunks (202721 bytes)
  after: 187 chunks (193550 bytes) : 5% smaller
https://www.redditstatic.com/gtm.aX_QHhLRPyo.js:1:0
  before: 15 chunks (18293 bytes)
  after: 15 chunks (17311 bytes) : 5% smaller
https://www.googletagmanager.com/gtm.js?id=GTM-5XVNS82&l=googleTagManager:1:0
  before: 150 chunks (214683 bytes)
  after: 150 chunks (209051 bytes) : 3% smaller
https://www.redditstatic.com/gtm-jail.jTMwZME_TT8.js:1:0
  before: 12 chunks (17339 bytes)
  after: 12 chunks (16542 bytes) : 5% smaller
https://www.redditstatic.com/desktop2x/PushNotifications.8cb929fcd04799e5f506.js:1:0
  before: 17 chunks (26330 bytes)
  after: 17 chunks (24482 bytes) : 7% smaller
https://www.redditstatic.com/desktop2x/reddit-components-SidebarNativeAd.74e367bda8613b8b8ec3.js:1:0
  before: 10 chunks (80210 bytes)
  after: 10 chunks (79346 bytes) : 1% smaller
https://tpc.googlesyndication.com/safeframe/1-0-37/js/ext.js:1:0
  before: 45 chunks (70235 bytes)
  after: 45 chunks (68647 bytes) : 2% smaller
https://reddit-d.openx.net/w/1.0/jstag:1:0
  before: 139 chunks (193861 bytes)
  after: 139 chunks (181728 bytes) : 6% smaller

so, 1-7% reduction.

Comment 4

[Tooru Fujisawa [:arai]]

I've looked into integrating DelazificationInfo into Parser/BytecodeEmitter, but several code there is shared between initial and delazification,
and I think adding branch for CompilationInfo/DelazificationInfo there isn't much optimal.
(some consumer can be replaced to use specific struct like CompilationInput tho, SharedContext/ParseContext cannot easily...)

So, if the runtime cost for converting CompilationInfo to DelazificationInfo worth perf/size improvement around XDR, I'd go with it.

Comment 5

[Tooru Fujisawa [:arai]]

there's not much difference in performance (no improvement, no regression), so this can be used to reduce XDR size, once the size becomes problematic, like:

• encoded size on disk
• in-memory size (bug 1662156 etc)

Comment 6

[Tooru Fujisawa [:arai]]

Updated plan:

• move initial-specific fields out of ScriptStencil, and store in separate vector, and refer it by index into the vector
  • starting from “SourceExtent`, and move more fields gradually
• move pointers out of ScriptStencil (bug 1678458 and bug 1678705)

once all of them are done, delazification vector contains only necessary info, while we don't need separate top-level stencil struct for each.

Comment 7

[Tooru Fujisawa [:arai]]

maybe this should be addressed by separate bug for each field

Comment 8

[Tooru Fujisawa [:arai]]

Attachment: Bug 1669718 - Introduce ScriptStencilExtra to store initial-parse-specific data. r?tcampbell!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/713a96d423db
Introduce ScriptStencilExtra to store initial-parse-specific data. r=tcampbell

Comment 10

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/713a96d423db