bazelbuild/bazel

Add size-bounded GC of the repo contents cache

Open

#29557 opened on May 16, 2026

View on GitHub
 (0 comments) (0 reactions) (0 assignees)Java (25,384 stars) (4,465 forks)batch import
P2help wantedteam-ExternalDepstype: feature request

Description

Description of the feature request:

Let users put a size ceiling on the repo contents cache. As far as I can tell, today, the only eviction signal is age (--repo_contents_cache_gc_max_age), so on busy workspaces the cache grows without bound until the age window kicks in. A companion size-based knob would let users say "keep this cache under 20 GB" and have Bazel evict the oldest entries to honour it: matching the pair of knobs the disk cache already exposes (added in #23833).

Which category does this issue belong to?

Performance

What underlying problem are you trying to solve with this feature?

The repo contents cache (introduced via #12227, made GC-aware in #26080) only supports age-based eviction today. A few workflow patterns combine to make the cache grow faster than the age window evicts:

  • Multiple workspaces / git worktree checkouts sharing one --repo_contents_cache. Every workspace adds entries; none individually feels the cost.
  • MODULE.bazel churn: version bumps, added or removed modules shifts predeclared-input-hashes. Old entries are no longer referenced but still don't age out for 14 days.
  • Every touch resets an entry's age clock, so the cache grows with the working-set size of all dependency churn over the age window, not with what's in use today.

Concrete: the contents/ directory under one of my caches grew to ~91 GB within a single 14-day window before disk pressure forced a manual rm -rf (on a dev laptop). A user wanting to keep it under (say) 20 GB has no tool for it short of deleting the directory by hand.

The disk cache already has both knobs, this asks for parity.

Which operating system are you running Bazel on?

macOS 26.4.1

What is the output of bazel info release?

release 8.7.0 (currently upgrading to 9)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

cc:

  • @Wyverald (PR #26080, original repo contents cache GC)
  • @tjgq (PR #23833, disk cache GC pattern this mirrors)

Contributor guide

Tech stack
java
Domain
build systemperformance
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
JavaBazel internalscache eviction
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Study the existing age based GC in RepositoryCache.java and the disk cache GC pattern from PR #23833. Implement a new repo contents cache max size flag similar to disk cache max size. Modify the eviction logic to delete oldest entries when size exceeds limit. Refer to the files in src/main/java/com/google/devtools/build/lib/remote/ for disk cache implementation patterns.