Proposal: Unified Low-Resource Execution Path for Chromium (Comparison Insight from WebKit Behavior)

[Erfan Mohebali]

Dear Chromium Engineering Team,

I would like to propose an exploration into a unified low-resource execution path for Chromium. Modern devices frequently enter states where memory pressure, CPU limits, and power-saving requirements sharply increase; in these scenarios, Chromium’s behavior remains less adaptive than desired because each subsystem—Blink, V8, Process Model, Scheduler, Viz/Skia, and PartitionAlloc—responds independently.

A concise comparison point is WebKit, which under constrained conditions benefits from:

• A tighter process model with lower fragmentation

• More aggressive memory reclamation (decoded images, layout caches, raster buffers)

• Conservative JIT behavior that avoids CPU spikes

• Lower compositor and raster activation frequency
  These characteristics allow WebKit to degrade more gracefully on low-resource systems while remaining fully functional.

A similar unified mode in Chromium could coordinate key subsystems as follows:

Process Model

• Dynamic renderer consolidation under MemoryPressureLevel::CRITICAL (e.g., via RenderProcessHostImpl::ShouldUseProcessPerSite()).

Blink

• Earlier transitions to low-activity lifecycle states and stronger cache purging using existing hooks:
  PageSchedulerImpl::UpdateLifecycleState(),
  DecodedImageMemory::PurgeAll(),
  HeapController::ScheduleIdleGC().

V8

• Limiting background compilation threads and reducing speculative optimizations in:
  Compiler::Optimize(), OptimizingCompileDispatcher::ScheduleJob(),
  and lowering concurrency in GC via Heap::StartConcurrentMarking().

Scheduler / ThreadPool

• Temporary reduction of ThreadPool concurrency and idle-task wakeups to avoid unnecessary CPU activation.

Viz / GPU / Skia

• Lowering BeginFrame cadence (DisplayScheduler::ScheduleNextBeginFrame())

• Batching or delaying raster operations (GpuRasterBufferProvider::ScheduleTasks())

• Optional CPU raster fallback in extreme cases.

PartitionAlloc

• Reducing per-thread cache budgets and accelerating page purges during OS memory-pressure notifications.

Such a unified, cross-subsystem mode would allow Chromium to exhibit predictable and efficient scaling under low-resource conditions—similar to WebKit’s operational patterns—while maintaining Chromium’s security guarantees and performance characteristics under normal load.

This proposal is intentionally concise, and I would be pleased to expand it into a deeper technical note if the idea aligns with the team’s direction.

Thank you for your time and consideration.

Best regards,