This fixes a crash resulting from a race between loading an initial
document and navigating to a subsequent document. If the navigation
happens before the initial document has had a chance to create its
root page, we crash trying to unwrap a None. Note that the are likely
further similar timing issues with more complex sequences of navigation
and history manipulation.
Source-Repo: https://github.com/servo/servo
Source-Revision: 30ffd09eb3daf4b0bc55627c281016f8f246fd6f
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
The script crate had its own built-in profiling which was basically doing the same thing as the profile crate. This wraps the internal profiling around the main profile functionality. Script-related tasks are now added to the ProfilerCategory enum.
Source-Repo: https://github.com/servo/servo
Source-Revision: ca36779a7e8298918b21ae243a43a71b1520119b
Elided almost all the lifetimes and removed needless returns. Mostly done by sed + manual fixes.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: c2c2646d37614ece5869af861993c3d619f6e003
I fear the category names are unimaginative; in some cases they may even be misleading or downright incorrect. Requests to rename categories as well as any other feedback are highly appreciated.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6431e8da43817e8a6b1e4757afbcf45c1a629707
Now that `JSRef<T>` is gone, there is no need to have helper traits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 909429702972d53bf02dfe9a4aa93ea0cb588cf4
The integration is off by default for now. You can try it out with `./mach build --features "script/plugins/clippy"`.
We're using a branch of clippy with some of the lints changed to Allow, either because they don't apply to us, or because they're noisy and dwarf other warnings (but still should be fixed)
After going through the rest of Servo's warnings I'll figure out which lints we should be keeping.
There's a cargo bug with optional deps that makes it hard for this to work with Cargo.lock -- so this PR contains no changes to lockfiles (and running the build with clippy on may dirty the lockfile, though it gets fixed later)
Source-Repo: https://github.com/servo/servo
Source-Revision: 50e1c967e4299c1515575f73d407f5f6b977d818
and `for foo in bar.iter_mut(), and for foo in bar.into_iter()
(continuation of #7197)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0d6d6a05009606dfbbfc9765d7dc2c745c18f6a5
These are caused by page_root being empty.
@jdm, I think it was #6874 that introduced these. I'm seeing them all the time when starting Servo on Reddit with memory profiling enabled. With this patch applied they go away.
Source-Repo: https://github.com/servo/servo
Source-Revision: 72fa45155b93a9763967cf215e3a9e60e3883cd9
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
... for #3734, which is also one of the oldest issues. (/cc @jdm)
Source-Repo: https://github.com/servo/servo
Source-Revision: 6a52ec94840fbaf43a29d76879e2b59542a9963d
This is handled in the 'navigate' algorithm in the specification.
Source-Repo: https://github.com/servo/servo
Source-Revision: e44ae6404fd25ed51a543141ca8f9cc2a3443817
…s for frame treese in script tasks.
This underreports by a significant amount, since only Document, Window and CharacterData (ie. text) nodes are fully represented. That being said, every HTML element in the tree is measured, but only counted as a Node. It's easy to improve this, it just requires adding the appropriate HeapSizeOf derives and increasing the granularity of `measure_memory_for_eventtarget`. google.com shows a dom-tree value of 0.24 MB for me at the moment.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: 84e25befdd97cf74fb00707dbe150d59d980e977
For now, this just gives some purpose to the abandoned receiver and later selects over the two receivers (for #6767). (oh wait, forgot to check the local build - there are still a few errors)...
Source-Repo: https://github.com/servo/servo
Source-Revision: effb17b3368769baaf5247908b26b7f0dd370ea3
This change makes Servo use serialized messages over IPC channels for resource loading. The goal is to make it easier to make Servo multiprocess in the future. This patch does not make Servo multiprocess now; there are many other channels that need to be changed to IPC before that can happen. It does introduce a dependency on https://github.com/serde-rs/serde and https://github.com/pcwalton/ipc-channel for the first time.
At the moment, `ipc-channel` uses JSON for serialization. This is because serde does not yet have official support for bincode. When serde gains support for bincode, I'll switch to that. For now, however, the JSON encoding and decoding will constitute a significant performance regression in resource loading.
To avoid having to send boxed `AsyncResponseTarget` trait objects across process boundaries, this series of commits changes `AsyncResponseTarget` to wrap a sender only. It is then the client's responsibility to spawn a thread to proxy calls from that sender to the consumer of the resource data. This only had to be done in a few places. In the future, we may want to collapse those threads into one per process to reduce overhead. (It is impossible to continue to use `AsyncResponseTarget` as a boxed trait object across processes, regardless of how much work is done on `ipc-channel`. Vtables are fundamentally incompatible with IPC across mutually untrusting processes.)
In general, I was pretty pleased with how this turned out. The main changes are adding serialization functionality to various objects that `serde` does not know how to serialize natively—the most complicated being Hyper objects—and reworking `AsyncResponseTarget`. The overall structure of the code is unchanged, and other than `AsyncResponseTarget` no functionality was lost in moving to serialization and IPC.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 2eb122f394651232abd683fc576a5c4288bf277f
Credits for Mike Blumenkrantz (@zmike), I just rebased against trunk and
fixed the url serialization.
Fixes#6178.
Source-Repo: https://github.com/servo/servo
Source-Revision: 82e476fd07564f2822a5af1f397751027ddf7258
This prevents them from piling up endlessly if the JS
`requestAnimationFrame()` callback takes a long time to complete.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 12c46ddd6131533454e353fa8fdd8cb4b517ffd0
This is used for two memory reporting improvements.
- It's used to distinguish "explicit" memory reports from others. This
mirrors the same categorization that is used in Firefox, and gives a single
tree that's the best place to look. It replaces the "pages" tree which
was always intended to be a temporary stand-in for "explicit".
- It's used to computed "heap-unclassified" values for both the jemalloc
and system heaps, both of which are placed into the "explicit" tree.
Example output:
```
| 114.99 MiB -- explicit
| 52.34 MiB -- jemalloc-heap-unclassified
| 46.14 MiB -- system-heap-unclassified
| 14.95 MiB -- url(file:///home/njn/moz/servo2/../servo-static-suite/wikipe
dia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyc
lopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.49 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
| 1.36 MiB -- layout-worker-3-local-context
| 1.34 MiB -- layout-worker-0-local-context
| 1.24 MiB -- layout-worker-1-local-context
| 1.24 MiB -- layout-worker-4-local-context
| 1.16 MiB -- layout-worker-2-local-context
| 0.89 MiB -- layout-worker-5-local-context
| 0.38 MiB -- layout-task
| 0.31 MiB -- display-list
| 0.07 MiB -- local-context
| 1.56 MiB -- compositor-task
| 0.78 MiB -- surface-map
| 0.78 MiB -- layer-tree
```
The heap-unclassified values dominate the "explicit" tree because reporter
coverage is still quite poor.
Source-Repo: https://github.com/servo/servo
Source-Revision: bff5e325a89ab6621a049ac55c1da66e901c776c
This necessitated getting rid of the boxed trait object that was being
be passed between the script task and the image cache task.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: e13ebf712de444132a6cc90f394c121d8d751c4c
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: f778e0eecf7cd8a2b870d18c3c305ff10d6b1894
- Use SmallVec<[T; N]>
- Make find_iframe a free function
- Make ProgressEvent use enums for bubbles and cancelable
- Change README, as `rust-snapshot-hash` is just a text file
Source-Repo: https://github.com/servo/servo
Source-Revision: aafc3dfa963b466303d5f241d69036f211aaad00
SpiderMonkey provides an extremely fine-grained breakdown of memory
usage, but for Servo we aggregate the measurements into a small number
of coarse buckets, which seems appropriate for the current level of
detail provided by Servo's memory profiler. Sample output:
```
| 17.41 MiB -- url(file:///home/njn/moz/servo/../servo-static-suite/wikipedia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyclopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.48 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
```
Most of the changes are plumbing to get the script task communicating
with the memory profiler task.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2b0bdbe1c195f2f6dd7671981999d622c505fbc5
This will make it easier to adapt to IPC.
The trickiest part here was to make script tasks spawn new layout tasks
directly instead of having the pipeline do it for them. The latter
approach will not work in multiprocess mode, because layout and script
must run in the same address space and the pipeline cannot inject tasks
into another process.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: e06eaa0064f49bc215e3851f0a3686e1191b356a
fixes#6524. I had to make an additional change not mentioned in the ticket - adding the `#[feature]` to enable deriving custom traits but I assume that's expected at this time.
Source-Repo: https://github.com/servo/servo
Source-Revision: bbb39082e0f640400546d2084a450a8675820a82
