This removes the global object field from the script load context and gets the
global from the script loader / module loader where necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142833
This gives the module loader a field for the current global, since a module map
is only associated with a single global.
This adds a method to Document to tell the script loader when its global
changes. I'm not sure of when we do this exactly.
Differential Revision: https://phabricator.services.mozilla.com/D142831
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
