By doing this on either side of the call to the relevant tasks' start()
method, we don't need to store the mem::ProfilerChan or the reporter
name in the task itself.
Source-Repo: https://github.com/servo/servo
Source-Revision: cb52cc66581191b6f787a4a6d0d2844e2968b7eb
Also updates glutin with a crash fix that was exposed by this patch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ac80bff8e25be65e96daaf6b7403b11d23d561a
This checks every .toml file for an asterisk and prints an error if found.
Source-Repo: https://github.com/servo/servo
Source-Revision: 58e9bc6583b6ebbeb27e3b28a6b271ee48cd695a
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: ef9715203edf0a280d019b6e8823666f0e7020be
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
This was the preferred pattern between the deprecation of Vec::from_elem and
the addition of the count argument to the vec![] macro.
Source-Repo: https://github.com/servo/servo
Source-Revision: 556c0e1509cb48b90f492bcf0f25d0ed14b015d1
This removes the possibility of a panic by checking a constraint at compile
time rather than at run time.
Source-Repo: https://github.com/servo/servo
Source-Revision: d7cf58d6f15c1b96884a5aef210a5c5d244abf54
Since I made unsafe code opt-in in layout, the unsafe code in this module has
been reduced to a single unsafe impl, so there is no reason to allow it in
the entire module.
Source-Repo: https://github.com/servo/servo
Source-Revision: ce81745a8ece10a81b3caaf80da41d7824c5105a
Fixes jumpiness on lots of Web sites.
r? @mbrubeck
Source-Repo: https://github.com/servo/servo
Source-Revision: bbcd42773342a587a8515f34bdc3ca69a380c0a8
I wrote this patch that makes the test from #6542 render as expected but I am not confident it is actually the right fix. Should the padding be included in the 'ascent' metric for images, or am I just introducing a bug that happens to offset the one I'm trying to fix?
Source-Repo: https://github.com/servo/servo
Source-Revision: 0688488a7fd3caee423968b33d6c19d79f94d29a
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
Source-Repo: https://github.com/servo/servo
Source-Revision: a3821bf24094bf5bb2a9553e66b69da3b6430aa5
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: b876a54dce091e161b87340130446597dd864732
By definition of a weak pointer, these implementations cannot be safe.
Source-Repo: https://github.com/servo/servo
Source-Revision: 82be491fa318f742720dc0a31f6c1b24beb57a3d
Currently, we use UnsafeFlow and UnsafeLayoutNode, both of which are aliases
for (usize, usize) and thus interconvertible. This change should make it
clearer that the WorkQueue is not limited to one particular type.
Source-Repo: https://github.com/servo/servo
Source-Revision: 07a1e187f03484c5f326e48c4a5fed81c134d215
Currently only the end of the byte range is used, but I plan to use the full range in some follow-up work.
Fixes#6431. r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 26982cb547f479e1fbe9395b7fd9207078a6d8ee
> Here it is.
>
> ~~There's two major things that are unfinished here:~~
> - ~~Dealing with the unroot_must_root lint. I'm not sure about the value of this lint with the new rooting API.~~ Done.
> - ~~Updating the Cargo.locks to point to the new SM and SM binding.~~ Done.
>
> I also included my fixes for the rust update, but these will disappear in a rebase. A rust update is necessary to support calling `Drop` on `Heap<T>` correctly when `Heap<T>` is inside a `Rc<T>`. Otherwise `&self` points to the wrong location.
>
> Incremental GC is disabled here. I'm not sure how to deal with the incremental barriers so that's left for later.
>
> Generational GC works. SM doesn't work without it.
>
> The biggest change here is to the rooting API. `Root` was made movable, and `Temporary` and `JSRef` was removed. Movable `Root`s means there's no need for `Temporary`, and `JSRef`s aren't needed generally since it can be assumed that being able to obtain a reference to a dom object means it's already rooted. References have their lifetime bound to the Roots that provided them. DOM objects that haven't passed through `reflect_dom_object` don't need to be rooted, and DOM objects that have passed through `reflect_dom_object` can't be obtained without being rooted through `native_from_reflector_jsmanaged` or `JS::<T>::root()`.
>
> Support for `Heap<T>` ended up messier than I expected. It's split into two commits, but only because it's a bit difficult to fold them together. Supporting `Heap<T>` properly requires that that `Heap::<T>::set()` be called on something that won't move. I removed the Copy and Clone trait from `Heap<T>` so `Cell` can't hold `Heap<T>` - only `UnsafeCell` can hold it.
>
> `CallbackObject` is a bit tricky - I moved all callbacks into `Rc<T>` in order to make sure that the pointer inside to a `*mut JSObject` doesn't move. This is necessary for supporting `Heap<T>`.
>
> `RootedCollectionSet` is very general purpose now. Anything with `JSTraceable` can be rooted by `RootedCollectionSet`/`RootedTraceable`. Right now, `RootedTraceable` is only used to hold down dom objects before they're fully attached to their reflector. I had to make a custom mechanism to dispatch the trace call - couldn't figure out how to get trait objects working for this case.
>
> This has been tested with the following zeal settings:
>
> GC after every allocation
> JS_GC_ZEAL=2,1
>
> GC after every 100 allocations (important for catching use-after-free bugs)
> JS_GC_ZEAL=2,100
>
> Verify pre barriers
> JS_GC_ZEAL=4,1
>
> Verify post barriers
> JS_GC_ZEAL=11,1
Source-Repo: https://github.com/servo/servo
Source-Revision: e7808c526c348fea5e3b48af70b7f1a066652097
Sorry for not doing it yesterday, I couldn't.
cc @metajack @SimonSapin
Source-Repo: https://github.com/servo/servo
Source-Revision: 4ebb95ccd8e034007eacb447a054919ef4af2bf7
See #6376
r? @Ms2ger
Snaps don't exist yet, putting up the @larsbergstrom signal. The snap need not exactly match this commit, anything in the vicinity, or just master, should work really. (yay stability)
There's no particular reason behind this rustup except that I want to keep Servo running on almost-master as much as possible.
Source-Repo: https://github.com/servo/servo
Source-Revision: 67b121c0b82f4a2107d7b015f60bd025e04dc336
Passing a function that measures TLS to WorkQueue is a bit weird, but I can't see how else to measure that data.
Source-Repo: https://github.com/servo/servo
Source-Revision: f03f584895f80deb08c77c817f6655609c4ee97c
