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
We'll want some kind of backstop no matter what optimization algorithm we use.
We don't want to go too long without running any given task so we can find
regressions quickly and have a good merge candidate.
This pulls the logic that handles this out of the SETA strategy and into its
own strategy.
This will also make the SETA shadow scheduler more representative of what the
algorithm is doing.
Note in the future we may find ways to make this backstop more efficient (i.e
only run tasks that didn't run in the last 9 pushes for example).
Depends on D68621
Differential Revision: https://phabricator.services.mozilla.com/D68622
--HG--
extra : moz-landing-system : lando
This allows to nest strategies without having to register ever intermediate
composite strategy first. For example:
All(Any("skip-unless-schedules", "seta"), "backstop")
Prior to this patch, we'd need to register that 'Any' one first and then use it
in the 'All'.
Depends on D68620
Differential Revision: https://phabricator.services.mozilla.com/D68621
--HG--
extra : moz-landing-system : lando
I'd like to implement a 'backstop' strategy, such that it will prevent all other
optimizers from removing tasks under certain conditions (e.g every 10th push).
The nicest way to implement this seems to be an 'All' composite strategy
(similar to 'Either' which this patch renames to 'Any'). This means we could
do something like:
All("seta", "backstop")
which means we would only remove tasks if *all* substrategies say to remove
tasks.
Differential Revision: https://phabricator.services.mozilla.com/D68620
--HG--
extra : moz-landing-system : lando
Prior to this patch if we tried to extract extra data from an h264
sample but then found a partial NAL unit we'd discard the already found extra
data rather than processing it. This is problematic for avc3 streams where
encryption starts during a NAL unit, as even if we'd seen extra data prior to
finding such a partial unit, we'd discard it.
With this patch we will instead process the extra data we've already found in a
best effort attempt. If we get sent avc3 content that encrypts in band extra
data we'll still be in trouble, but I am not sure such content exists at this
stage.
This also changes our handling for non-encrypted streams, where we will now
also try to use any already discovered extra-data.
Differential Revision: https://phabricator.services.mozilla.com/D70767
--HG--
extra : moz-landing-system : lando
This undoes the changes from bug 1560092. These changes assumed that we couldn't
play encrypted avc3 content as we couldn't read SPS + PPS info from the stream.
However, after some testing I believe the issue is we can try and detect SPS +
PPS data in such streams, but need to better handle the encrypted case.
A following patch will address better handling SPS + PPS data in encrypted
streams.
Differential Revision: https://phabricator.services.mozilla.com/D70766
--HG--
extra : moz-landing-system : lando
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
--HG--
extra : moz-landing-system : lando
This fixes the content policy type for document loads in these frames, where
the explicit mIsFrame flag was not set, due to DocShell creation taking a
different code path in remote frames than in in-process frames.
Differential Revision: https://phabricator.services.mozilla.com/D52093
--HG--
extra : moz-landing-system : lando
