When performing the last GC, remaining state watchers would dispatch direct tasks ; this was exposed with P3. Ensure this never happens.
Differential Revision: https://phabricator.services.mozilla.com/D75499
During the last cycle collection, state watchers may attempt to dispatch tasks to the current AbstractThread, so we can't clear the TLS entry until that step has completed.
We want the object to be deleted last; ordering in call to ClearOnShutdown() can't guarantee it.
Differential Revision: https://phabricator.services.mozilla.com/D75498
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75366
We already ensure that we finish our write before doing a fast
shutdown, but right now there's just too much noise in the late
write checking telemetry because of this.
Differential Revision: https://phabricator.services.mozilla.com/D75389
Gecko Idle detection relies heavily on RefreshDriver. GC/CC scheduling, including when to run GC or CC slices, and the length of the slices, is mostly based on idle time. As WebXR isn't using normal RefreshDriver, the content process thinks it's idle and GC and CC get basically up to 50 ms slices.
Not having WebXR idle detection is causing stutter frames during immersive presentation. This patch implements idle deadline hint and sets the correct GC slices budgets during WebXR presentation.
Differential Revision: https://phabricator.services.mozilla.com/D74426
Bug 1536796 introduces "\\?\" prefix (DOS device specifier) to Windows file
paths. At the moment, the prefix is only prepended to the file paths that start
with a disk designator and a backslash.
On the other hands, IsBlockedUNCPath blocks file paths that start with "\\" in
Windows and that includes DOS device paths (the cases mentioned above).
Thus, this patch prevents DOS device paths from being treating as UNC paths in
IsBlockedUNCPath.
Differential Revision: https://phabricator.services.mozilla.com/D73621
This wraps the current thread such that a call to Dispatch will be done as direct task dispatch instead so that the task will be run in the current event loop.
This allows for have similar (but not identical to) the microtask semantics of JS promises
Differential Revision: https://phabricator.services.mozilla.com/D69995
If set, the callback will be dispatched via a direct task.
Direct tasks are run via the current thread's tail dispatcher.
This mechanism is only available if both the caller and the target are on the same thread and an AbstractThread is available
Differential Revision: https://phabricator.services.mozilla.com/D71592
In Python 3, iteration order over the contents of a native `dict` is always unpredictable, which results in bugs like bug 1635755 where `xptdata.cpp` has irreproducible content. To avoid this, we be sure to always write out JSON in a fixed, deterministic order.
Differential Revision: https://phabricator.services.mozilla.com/D74443
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
This file is used by the searchfox indexer using python2, so maintaining
py2-compatibility is desirable if not unduly burdensome.
Differential Revision: https://phabricator.services.mozilla.com/D74224
The place where it's done right now is just unsound. It modifies
attributes during frame construction and it causes assertions to fire
with lazy frame-construction enabled.
Differential Revision: https://phabricator.services.mozilla.com/D74029
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821