This patch adds a new off-thread delazification strategy, which adds a bit of
overhead to queue function with a priority order, which put the largest function
as the first functions to be delazified.
The intent of this new strategy is to limit the usage of main-thread
delazification to the smallest function, in case where the main-thread would win
the delazification race.
Differential Revision: https://phabricator.services.mozilla.com/D149651
Adds a delazification mode, which spawn a concurrent depth-first delazification
of all function to fill the stencil cache, to later compare cached results with
stencils produced by on-demand delazification.
The delazification mode also works when being used from a main-thread top-level
compilation, in which case the delazification tasks are created and potentially
blocking the main thread, while the delazification is happening.
This way of doing help comparing on-demand delazification, based on instantiated
stencils with concurrent delazification, based on stencils. Which is a good
mode for fuzzing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145992
This is necessary for putting all global `var`s in `ModuleEnvironmentObject`,
instead of local slot, so that they're accessible in Part 4 patch.
Differential Revision: https://phabricator.services.mozilla.com/D146033
Adds a delazification mode, which spawn a concurrent depth-first delazification
of all function to fill the stencil cache, to later compare cached results with
stencils produced by on-demand delazification.
The delazification mode also works when being used from a main-thread top-level
compilation, in which case the delazification tasks are created and potentially
blocking the main thread, while the delazification is happening.
This way of doing help comparing on-demand delazification, based on instantiated
stencils with concurrent delazification, based on stencils. Which is a good
mode for fuzzing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145992
This is necessary for putting all global `var`s in `ModuleEnvironmentObject`,
instead of local slot, so that they're accessible in Part 4 patch.
Differential Revision: https://phabricator.services.mozilla.com/D146033
Adds a delazification mode, which spawn a concurrent depth-first delazification
of all function to fill the stencil cache, to later compare cached results with
stencils produced by on-demand delazification.
The delazification mode also works when being used from a main-thread top-level
compilation, in which case the delazification tasks are created and potentially
blocking the main thread, while the delazification is happening.
This way of doing help comparing on-demand delazification, based on instantiated
stencils with concurrent delazification, based on stencils. Which is a good
mode for fuzzing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145992
This patch adds the ability to dump most of the content of CompilationInput.
To avoid adding extra dependencies in CompileOptions.h, a method named
`dumpWith` is added, and uses a template parameter to let the caller implement
what has to be done for each fields, with the expectation that C++ overloading
would be used to distinguish between the various types.
Differential Revision: https://phabricator.services.mozilla.com/D141511
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
Previously, we had only 2 modes, either we delazify everything on demand, when
the code is being executed, or we delazify everything ahead when doing the
syntax parsing.
These 2 modes will have to be refined in the future, to reduce the number of
delazified function which are written in the bytecode cache, and to eagerly and
concurrently delazify function out-side the main-thread and out-side the syntax
parsing phase.
This change add a `DelazificationOption` type to enumerate the various modes
which could be a middle ground between these 2 options, and replaces the
`forceFullParse_` flag, as it is a specialized case of the delazification
option.
Differential Revision: https://phabricator.services.mozilla.com/D136336
In order to support allocating CompilationGCOutput off main thread with
stencil-based off-thread API, add public type that wraps CompilationGCOutput,
and make stencil-based off-thread API return pre-allocated CompilationGCOutput
if the `options.allocateInstantiationStorage` is true.
Differential Revision: https://phabricator.services.mozilla.com/D133041
In order to support allocating CompilationGCOutput off main thread with
stencil-based off-thread API, add public type that wraps CompilationGCOutput,
and make stencil-based off-thread API return pre-allocated CompilationGCOutput
if the `options.allocateInstantiationStorage` is true.
Differential Revision: https://phabricator.services.mozilla.com/D133041
Changed all off-thread tasks not to use parse global.
Removed bug-1138390.js because off-thread script decode no longer wait for GC.
* ParseTask::parseGlobal is removed in Part 2
* OffThreadParsingMustWaitForGC is removed in Part 3
* GlobalHelperThreadState::parseWaitingOnGC is removed in Part 3
* GlobalHelperThreadState::generateLCovSources is removed in Part 5
* ParseTask::scripts is removed in Part 6
* ModuleObject::fixEnvironmentsAfterRealmMerge is removed in Part 7
* Zone::{setCreatedForHelperThread,clearUsedByHelperThread} are removed in
bug 538450
* RealmCreationOptions::setMergeable is removed in bug 1655768
* MergeRealms is removed in bug 1655768
Differential Revision: https://phabricator.services.mozilla.com/D131354
Adds a new preference javascript.options.use_fdlibm_for_sin_cos_tan (default
false) and uses fdlibm for Math.sin, Math.cos, and Math.tan conditioned on it.
Differential Revision: https://phabricator.services.mozilla.com/D119426
Adds a new preference javascript.options.use_fdlibm_for_sin_cos_tan (default
false) and uses fdlibm for Math.sin, Math.cos, and Math.tan conditioned on it.
Differential Revision: https://phabricator.services.mozilla.com/D119426
While removing unnecessary `mozilla::Maybe` in the last part, I've noticed that
this header has many unused or unnecessary includes.
Depends on D121743
Differential Revision: https://phabricator.services.mozilla.com/D121745
When reporting an invalid asm.js heap length, we must also guard the
message on the max such heap length or we risk asserting in the function
that computes the max heap length from the given invalid length.
Drive-by fix: Better error reporting for link errors.
Differential Revision: https://phabricator.services.mozilla.com/D115464
When reporting an invalid asm.js heap length, we must also guard the
message on the max such heap length or we risk asserting in the function
that computes the max heap length from the given invalid length.
Drive-by fix: Better error reporting for link errors.
Differential Revision: https://phabricator.services.mozilla.com/D115464
Instead of setting the realm-behaviour on the self-hosted realm, set it on the
CompileOptions directly when parsing. This is in preparation for removal of the
self-hosted Zone. Also set NoScriptRVal at same time.
Differential Revision: https://phabricator.services.mozilla.com/D115028
The computation of CompileOptions captures only the asmjs flag value,
but this is insufficient to determine if asmjs compilation is actually
supported: we must also determine whether a wasm compiler is available
to compile the wasm that is emitted by the asmjs front end.
This has been a pretty typical error pattern for us in the past, hence
the introduction of the class of wasm::WhateverAvailable(cx)
predicates to work around this. That fix needs to be used here too.
This patch adds the necessary check to the computation of
CompileOptions and for maximum clarity also distinguishes this case
from the case where the asmjs pref is turned off, even though that's
not necessary. A couple of new predicates are introduced to keep the
check clean.
Differential Revision: https://phabricator.services.mozilla.com/D114479