Create fewer ModuleRequestObjects
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
Details
Attachments
(4 files)
The way module metadata works at the moment is that we create a separate ModuleRequestObject per stencil StencilModuleEntry. Since there is an entry for every requested module and also one entry per import we will usually create about twice as many as needed. Import statements that import multiple names are worse because there is a separate entry per name.
We should try and share ModuleRequestObjects where possible.
|
Assignee | |
Comment 1•1 year ago
|
||
I spent a while investigating turning ModuleRequestObject from a separate GC thing into a sub-object of RequestedModule/ImportEntry/etc. However ModuleRequestObject is used in the asynchronous dynamic module loading APIs however and the fact that we don't need to worry about it staying alive makes this easier to reason about.
The following patches do the simple thing and share a ModuleRequestObject between the RequestedModule/ImportEntry/ExportEntry data for a single JS import or export statement. The improvement from doing a full deduplication is likely marginal.
|
|
Assignee | |
Comment 2•1 year ago
|
||
Not related to the rest of the bug. This is a simplification so that we set the
supported import assertions once rather than querying the host every time they
are needed.
|
|
Assignee | |
Comment 3•1 year ago
|
||
For local exports there is no module specifier (and no assertions) present so
there's no need to create an object for them. The module request is never
accessed for local exports, except in test code.
Depends on D164914
|
|
Assignee | |
Comment 4•1 year ago
|
||
This moves the module specifier and assertion information out of
StencilModuleEntry into a new StencilModuleRequest structure. These are
referred to by (optional) index into a vector of all requests for that mode. We
only create one request per statement.
Depends on D164915
|
|
Assignee | |
Comment 5•1 year ago
|
||
Finally, this creates a vector of ModuleRequestObjects at the start of
StencilModuleMetadata::initModule so we can use the index from the stencil data
to get the right one.
Depends on D164916
Pushed by jcoppeard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/aa187ddcaa8a Part 0: Change the API so that the supported assertions are set once on initialization r=arai https://hg.mozilla.org/integration/autoland/rev/2edb6fac4d4e Part 1: Don't create ModuleObjectRequests when there's no specifier r=arai https://hg.mozilla.org/integration/autoland/rev/1db0decb511e Part 2: Factor out StencilModuleRequest from StencilModuleEntry r=arai https://hg.mozilla.org/integration/autoland/rev/6be3e866b031 Part 3: Create one ModuleRequestObject per StencilModuleRequest r=arai
|
||
Comment 7•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/aa187ddcaa8a
https://hg.mozilla.org/mozilla-central/rev/2edb6fac4d4e
https://hg.mozilla.org/mozilla-central/rev/1db0decb511e
https://hg.mozilla.org/mozilla-central/rev/6be3e866b031
Description
•