If a CC takes too long (around 50 slices) or gets interrupted by a GC,
we have to finish it synchronously, which can cause a big pause.
This patch tries to avoid that by eagerly increasing the slice budget
the longer a CC goes on. It linearly increases the slice time from 5ms
to 40ms as we approach the halfway point of a CC (1 second), matching
GC pauses, and then leaves it at 40ms.
This patch fixes two related issues.
1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to
communicate with its callback during each compartment switch.
This vector was designed to allow its contents to be stack-allocated
but they turned out to be accidentally heap-allocated.
2. During each tick, the stopwatch fills a vector `recentGroups_`.
This vector always started with minimal capacity and had to grow
repeatedly as groups were added, causing repeated reallocations.
This patch preallocates `recentGroups_` to have the same capacity as the
previous tick. We expect that this should eventually reach a stable size
that closely matches the actual needs of the process.
This patch fixes two related issues.
1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to
communicate with its callback during each compartment switch.
This vector was designed to allow its contents to be stack-allocated
but they turned out to be accidentally heap-allocated.
2. During each tick, the stopwatch fills a vector `recentGroups_`.
This vector always started with minimal capacity and had to grow
repeatedly as groups were added, causing repeated reallocations.
This patch preallocates `recentGroups_` to have the same capacity as the
previous tick. We expect that this should eventually reach a stable size
that closely matches the actual needs of the process.
Follow-up to Janek's port in 462332eee018e24d88255c708fa8acb67a717673
where this variable was changed creating a mismatch with surrounding
code.
This fixes#943.
When we are reading large image data (i.e.: people using webp to stream
video instead of the native webm format; I'm looking at you, Giphy!)
we can run into the situation where the available data is not in a
contiguous buffer, and we need to either buffer additional data or
re-buffer from the start. If we don't do this, we can run into issues
because of buffer over-reading (causing corrupted data if allocated or
more likely crashes if not allocated).
Re-buffering is expensive, but this should be rare and limited to
dealing with unintended use for animated image formats.
This resolves#940.
When a node is released/removed, and it has an intersection observer
attached to it, that observer should be unlinked at the time of release.
This resolves#935.
