fix(runtime): reduce memory retention after web worker termination#32617
Merged
bartlomieju merged 4 commits intomainfrom Mar 12, 2026
Merged
fix(runtime): reduce memory retention after web worker termination#32617bartlomieju merged 4 commits intomainfrom
bartlomieju merged 4 commits intomainfrom
Conversation
Two changes to help RSS go down after workers are destroyed (#26058): 1. Call `malloc_trim(0)` on Linux after each worker thread exits. When a worker's V8 isolate and tokio runtime are dropped, the freed memory often isn't returned to the OS because glibc's allocator holds onto fragmented heap pages. This matches the existing SIGUSR2 handler pattern already used in the main worker. 2. Replace the OS thread used for the 2-second termination fallback timer with a tokio task. Previously, each worker termination spawned a raw `std::thread` just to sleep(2s) and call `terminate_execution()`. With rapid worker churn (e.g. 100 workers at a time), this created many short-lived OS threads. A tokio timer is much lighter weight. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
nathanwhit
requested changes
Mar 11, 2026
The 2-second timer fallback for terminating workers is no longer needed since the upstream V8 issue has been fixed. Workers now terminate cooperatively via the termination signal and event loop wakeup. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
kajukitli
approved these changes
Mar 12, 2026
Contributor
kajukitli
left a comment
There was a problem hiding this comment.
lgtm
removing the 2s forced-termination hack is the right call if the upstream V8 issue is actually gone. that path was always gross: extra thread per terminate, weird delayed kill semantics, and easy to leak thread churn under worker-heavy workloads.
malloc_trim(0) after the worker runtime/isolate drops also makes sense as a targeted Linux-only mitigation for the RSS retention problem.
one caveat is that malloc_trim(0) is process-global and can be a little expensive if workers churn hard, but given this is specifically trying to reduce post-worker RSS and it's Linux-only, i think the tradeoff is reasonable.
nathanwhit
approved these changes
Mar 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses #26058 — Web Workers use significantly more RSS than Chrome, and terminating them doesn't release the memory back to the OS.
Two targeted changes:
Call
malloc_trim(0)on Linux after each worker thread exits. When a worker's V8 isolate and tokio runtime are dropped, glibc's allocator holds onto the fragmented heap pages rather than returning them to the OS. This explicitly asks glibc to release them. Follows the same pattern already used in the SIGUSR2 memory trim handler (runtime/worker.rs:81).Remove the delayed termination hack entirely. The 2-second timer that spawned threads/tasks to force-terminate workers is no longer needed — the upstream V8 issue that required it has been fixed. Workers now terminate cooperatively via the termination signal and event loop wakeup, which also eliminates the ~100 lingering OS threads during rapid worker churn.
What this doesn't fix
malloc_trimis Linux-only)