Move the TI heuristic into BCE::emitFunction where the other special mutation
of inner-functions is happening.
Differential Revision: https://phabricator.services.mozilla.com/D70781
--HG--
extra : moz-landing-system : lando
Instead rely on consistent definitions of the TreatAsRunOnce flag on the
SharedContext. Also simplify the BCE::check{RunOnce,Singleton}Context
accessors. Note that the TreatAsRunOnce flag indicates the script is expected
to run-once, but the BCE also checks for isInLoop to decide if current
bytecode location within the script should still be considered run-once.
Differential Revision: https://phabricator.services.mozilla.com/D70780
--HG--
extra : moz-landing-system : lando
Use the same conditions for qualifying an inner function as a run-once-lambda
between the lazy and non-lazy code paths. Use the FunctionBox::immutableFlags
so that this works well with delazification too.
Differential Revision: https://phabricator.services.mozilla.com/D70779
--HG--
extra : moz-landing-system : lando
In the BytecodeEmitter constructor, initialize the TreatAsRunOnce flag for
top-level SharedContexts. In the future we should initialize this even
earlier. For the delazification case, we initialize already directly
initialize this flag from the lazy BaseScript.
Differential Revision: https://phabricator.services.mozilla.com/D70778
--HG--
extra : moz-landing-system : lando
The interpreter calls `TierUpTick` whenever we interpret a regexp. Once we hit the tick threshold, compileIfNecessary will compile native code for the regexp.
Currently the tick threshold is hard-coded to 10. V8's tick threshold is 1, which seems unreasonably low. We can tune this later.
Differential Revision: https://phabricator.services.mozilla.com/D70952
--HG--
extra : moz-landing-system : lando
The current ForceByteCodeEnum is a glorified boolean. This patch replaces it with a three-value bytecode/jitcode/either enum, which will make our tiering-up logic slightly nicer in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D70951
--HG--
extra : moz-landing-system : lando
Internally, irregexp uses -1 for errors, 0 for failure, and 1 for success. We have to use the same values in RegExpRunStatus.
Ideally we would replace RegExpRunStatus with an enum defined in RegExpTypes.h, but that will have to wait until we get rid of the old import.
Differential Revision: https://phabricator.services.mozilla.com/D70728
--HG--
extra : moz-landing-system : lando
The irregexp compiler takes the AST produced by the parser, compiles it down to a more efficient internal representation, then uses a 'macroassembler' to generate code. The generated code can either be bytecode (which is then fed into the interpreter) or jitcode (which can be executed directly).
This patch gets the infrastructure set up and handles the former case.
CompilePattern is based heavily on V8's `RegExpImpl::compile` (affc364620/src/regexp/regexp.cc (L745-L933)). I am upstreaming a patch to move the code in WrapBody into regexp-compiler.cc where it fits better.
V8 is about to land a patch to tweak the API for Interpret so that it allocates memory for its registers internally instead of requiring it to be passed in. When we import this change, we'll be able to pass `matches->pairsRaw()` directly into `MatchForCallFromRuntime`, and the interpreter will fill it in for us.
In the old engine, we could handle interrupts in the middle of the interpreter. If we hit an urgent interrupt in compiled code, we would generate bytecode and fall back to the interpreter (see https://searchfox.org/mozilla-central/rev/9120151ddb35f2d4c37bfe613a54a4f10a9a3dc5/js/src/vm/RegExpObject.cpp#1165-1175). (This is what all the `ForceByteCode` machinery in RegExpObject.cpp is about. It was added in bug 1077514.) That won't work in the new version. V8 does allow interrupts during regexp execution, but only by jumping through some scary hoops to "manually relocate unhandlified references" afterwards. Instead, we just retry the regexp. I have no idea what a reasonable number of retries is before giving up; I've arbitrarily picked 4 for now.
Differential Revision: https://phabricator.services.mozilla.com/D70695
--HG--
extra : moz-landing-system : lando
In preparation for actually compiling regexps in the next patch, hook up the V8 and irregexp representations of a compiled regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70694
--HG--
extra : moz-landing-system : lando
A regexp with N sets of capturing parens will have N+1 capture groups, with the extra capture containing the entire matching string. Our old implementation stored `parenCount` in the RegExpShared and then added 1 to it whenever it was used. A much simpler answer is to just add 1 when initializing the regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70693
--HG--
extra : moz-landing-system : lando
I left all the bits that related to grid container, such as setting
aStatus, NS_STATE_GRID_DID_PUSH_ITEMS, and aState.mIter in
nsGridContainerFrame::ReflowRowsInFragmentainer().
Differential Revision: https://phabricator.services.mozilla.com/D68492
--HG--
extra : moz-landing-system : lando
We have duplicated ReparentFrame and ReparentFrames define in both
nsBlockFrame and nsGridContainerFrame. We should move them into
nsContainerFrame.
Differential Revision: https://phabricator.services.mozilla.com/D68490
--HG--
extra : moz-landing-system : lando
And batch them when notifying child processes.
This makes RegisterVisitedQuery potentially notify synchronously, but changes
the code to deal with it properly.
Differential Revision: https://phabricator.services.mozilla.com/D69187
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
The semantics of sticky items are somewhat different from the semantics of
fixed items. For fixed items, if an item is fixed to eTop or eBottom or
eTopBottom, it is *always* fixed to those sides. For sticky items, however,
the sides actively stuck to are dependent on the scroll position. So we need
a mechanism to dynamically figure out which sides are stuck, and use those
sides when computing the fixed margins to apply. This patch implements that
by modifying the IsStuckToRootContentAtBottom method into a
SidesStuckToRootContent method.
Differential Revision: https://phabricator.services.mozilla.com/D70910
--HG--
extra : moz-landing-system : lando
I couldn't understand what it was doing before, but conceptually it should
be pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D70909
--HG--
extra : moz-landing-system : lando
This sets us up to be able to use these helper methods on WR sampling codepath.
Depends on D70907
Differential Revision: https://phabricator.services.mozilla.com/D70908
--HG--
extra : moz-landing-system : lando
This will make future patches simpler, as we can now create these info objects
more easily for the non-WR codepath as well.
Depends on D70906
Differential Revision: https://phabricator.services.mozilla.com/D70907
--HG--
extra : moz-landing-system : lando
We can use the map lock to do a lookup in mApzcMap, instead of requiring the
tree lock to call GetTargetAPZC.
Differential Revision: https://phabricator.services.mozilla.com/D70906
--HG--
extra : moz-landing-system : lando
Prior to this patch, the startupcache created its own mWriteThread off which it
wrote to disk. It's initialized by MaybeSpawnWriteThread, which got called
at shutdown, to do the shutdown write if there was any reason to do so, and
from a timer that is re-initialized after every addition to the startup cache,
to run 60s after the last change to the cache.
It then joined that write thread on the main thread (in other words, blocks
on that off-main-thread write completing from the main thread) when:
- xpcom-shutdown fired
- the startupcache itself gets destroyed
- someone calls any of:
* HasEntry
* GetBuffer
* PutBuffer
* InvalidateCache
This patch removes the separate write thread, and instead dispatches a task to
the background task queue, indicating it can block. The task is started in
the same circumstances where we previously used to write (timer from the last
PutBuffer call, and shutdown if necessary).
To ensure it cannot be trying to use the data it writes out (mTable) from
the other thread while that data changes on the main thread, we use a mutex.
The task locks the mutex before starting, and unlocks when finished.
Enumerating the cases that we used to block on joining the thread:
In terms of application shutdown, we expect the background task queue to
either finish the write task, or fail to run it if it hasn't started it yet.
In the FastStartup case, we check if a write was necessary; if so, we
attempt to gain the lock without waiting. If we're successful, the write has
not yet started, and we instead run the write on the main thread. Otherwise,
we retry gaining the lock, blocking this time, thus guaranteeing the
off-the-main-thread write completes.
The task keeps a reference to the startupcache object, so it cannot be
destroyed while the task is pending.
Because the write does not modify `mTable`, and neither does `HasEntry`,
we do not need to do anything there.
In the `GetBuffer` case, we do not modify the table unless we have to read
the entry off disk (memmapped into `mCacheData`). This can only happen if
`mCacheData.initialized()` returns true, and we specifically call
`mCacheData.reset()` before firing off the write task to avoid this.
`mCacheData` is only re-initialized if someone calls `LoadArchive()`,
which can only happen from `Init()` (which is guaranteed not to run
again because this is a singleton), or `InvalidateCache()`, where we lock
the mutex (see below). So this is safe - but we assert on the lock to try
and avoid people breaking this chain of assumptions in the future.
When `PutBuffer` is called, we try to lock the mutex - but if locking fails
(ie the background thread is writing), we simply fail to store the entry
in the startupcache. In practice, this should be rare - it'd happen if
new calls to PutBuffer happen while writing during shutdown (when really,
we don't care) or when it's been 60 seconds since the last PutBuffer so
we started writing the startupcache.
When InvalidateCache is called, we lock the mutex - we shouldn't try to
write while invalidating, or invalidate while writing. This may be slow,
but in practice nothing should call `InvalidateCache` except developer
restarts or the `-purgecaches` commandline flag, so it shouldn't
matter a great deal.
Differential Revision: https://phabricator.services.mozilla.com/D70413
--HG--
extra : moz-landing-system : lando
This patch integrates the majority of the mach-perftest-notebook project from the github project to the in-tree mozperftest package/tool. Certain portions of it are disabled in this integration (posting to iodide, and transform searching).
Differential Revision: https://phabricator.services.mozilla.com/D70134
--HG--
extra : moz-landing-system : lando
There is actually possible to start the listener already while running `SuspendOrResumeElement()`, so we should remove the assertion and use a check instead.
Eg. JS can call `play()`, which would start the listener, before we run this method. This situation can be found when browsing Youtube on the GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D69673
--HG--
extra : moz-landing-system : lando
When the docShell's `SuspendMediaWhenInactive` flag is true, no media should be allowed to start playing. Therefore, we add a check in `Play()`, `CanActivateAutoplay()` to prevent media from playing. In addition, we should also prevent the audio channel agant from starting.
Differential Revision: https://phabricator.services.mozilla.com/D69672
--HG--
extra : moz-landing-system : lando
If docShell's `SuspendMediaWhenInactive` is true, then we should suspend or resume the media element according to the docshell active state when the docshell changes it active state.
Differential Revision: https://phabricator.services.mozilla.com/D69671
--HG--
extra : moz-landing-system : lando
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
--HG--
extra : moz-landing-system : lando
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
--HG--
extra : moz-landing-system : lando
