LoAF: Report worker congestion from a saturated task queue The Long Animation Frame (LoAF) API today reports only individual long tasks in Web Workers. A worker's event loop can also be saturated by a flood of consecutive short tasks: no single task is long enough to be reported on its own, but together they keep the loop busy past the 200ms congestion threshold. This congestion is invisible to developers even though it blocks the worker just as effectively as a single long task. This CL lets the LoAF API detect such congestion in a Web Worker and report it as a long-animation-frame entry. Congestion is detected by queuing delay: a task that was already scheduled before the previous task started running means two tasks were queued at once (backlog depth >= 2). This is what separates real congestion from a steady async iteration, which keeps the loop busy without ever building a backlog and must not be reported. Once a congested moment opens, consecutive tasks are folded into a single saturated interval for as long as the thread does not actually go idle between them. The interval ends when the queue drains (a real idle gap), and is reported once as a single entry covering the whole interval. For a congestion entry, scriptCount counts every top-level script entry point folded into the interval even when scripts[] is empty (each task is under the 5ms attribution threshold), and blockingDuration is the span beyond the 200ms threshold. The behavior is gated behind the LongAnimationFrameWorker flag, so default behavior is unchanged. Main-thread congestion is handled in a separate CL. Run with --enable-blink-features=LongAnimationFrameWorker. Design Doc: https://docs.google.com/document/d/13tERlM0Cd8gKUDC01-lQeW4oNllKs4AKdEGw41bnH4k/edit?usp=sharing Test: third_party/blink/tools/run_web_tests.py -t release_x64 --additional-driver-flag=--enable-blink-features=LongAnimationFrameWorker external/wpt/long-animation-frame/loaf-congested-moment-worker.html Bug: 534893134 Change-Id: I69beb4a72021b2c4ac094c4ae5d14deabe796739 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8132581 Reviewed-by: Noam Rosenthal <nrosenthal@google.com> Reviewed-by: Scott Haseley <shaseley@chromium.org> Commit-Queue: Joone Hur <joonehur@microsoft.com> Cr-Commit-Position: refs/heads/main@{#1672187} NOKEYCHECK=True GitOrigin-RevId: 1d77c4bca902204d46136da93b7665ea017f3fa6
Contains a written down set of principles and other information on //base. Please add to it!
Chromium is a very mature project. Most things that are generally useful are already here and things not here aren't generally useful.
The bar for adding stuff to base is that it must have demonstrated wide applicability. Prefer to add things closer to where they're used (i.e. “not base”), and pull into base only when needed. In a project our size, sometimes even duplication is OK and inevitable.
Adding a new logging macro DPVELOG_NE is not more clear than just writing the stuff you want to log in a regular logging statement, even if it makes your calling code longer. Just add it to your own code.
If the code in question does not need to be used inside base, but will have multiple consumers across the codebase, consider placing it in a new directory under components/ instead.
base is written for the Chromium project and is not intended to be used outside it. Using base outside of src.git is explicitly not supported, and base makes no guarantees about API (or even ABI) stability (like all other code in Chromium). New code that depends on base/ must be in src.git. Code that's not in src.git but pulled in through DEPS (for example, v8) cannot use base.
Owners are added when a contributor has shown the above qualifications and when they express interest. There isn't an upper bound on the number of OWNERS.
Since the primitives provided by //base are used very widely, it is important to ensure they scale to the necessary workloads and perform well under all supported platforms. The base_perftests target is a suite of synthetic microbenchmarks that measure performance in various scenarios:
thread_local, the implementation in //base, the POSIX/WinAPI directly)Regressions in these benchmarks can generally by caused by 1) operating system changes, 2) compiler version or flag changes or 3) changes in //base code itself.
Rust code in base should be organized into very small crates, split up by function. Merging crates is sometimes unavoidable (due to dependency cycles or the orphaning rule).
Rust files should live near the equivalent C++ files (if any), and use the same naming scheme (for example, run_loop.rs, not run_loop_rust.rs).
When adding FFI shims, prefer separate _shim.h files rather than adding code to existing C++ files. This helps avoid circular dependencies with the //base target. It also avoids adding code to commonly-used headers, which can increase compile size by a lot.
Crates which you expect to be widely used should be added to the public_deps of the //base:base_rust target, so that developers can simply depend on //base:base_rust the same way they do with //base.