From db4a400806cee783cdcf8e4e67403f7a6ece028c Mon Sep 17 00:00:00 2001 From: Googler Date: Fri, 27 Sep 2024 08:05:37 -0700 Subject: [PATCH] Amend the description of DiskCacheClient to reflect the addition of automatic garbage collection. PiperOrigin-RevId: 679593657 Change-Id: I4f5aa03d88913702ab4c1b879bc2bc9b0c40f720 --- .../devtools/build/lib/remote/disk/DiskCacheClient.java | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/main/java/com/google/devtools/build/lib/remote/disk/DiskCacheClient.java b/src/main/java/com/google/devtools/build/lib/remote/disk/DiskCacheClient.java index 88845a7d92dc38..0b3acd2f3ccd66 100644 --- a/src/main/java/com/google/devtools/build/lib/remote/disk/DiskCacheClient.java +++ b/src/main/java/com/google/devtools/build/lib/remote/disk/DiskCacheClient.java @@ -54,8 +54,13 @@ * when they collide. * *

The mtime of an entry reflects the most recent time the entry was stored *or* retrieved. This - * property may be used to trim the disk cache to the most recently used entries. However, it's not - * safe to trim the cache at the same time a Bazel process is accessing it. + * property may be used to garbage collect the disk cache by deleting the least recently accessed + * entries. This may be done by Bazel itself (see {@link DiskCacheGarbageCollectorIdleTask}), by + * another Bazel process sharing the disk cache, or by an external process. Although we could have + * arranged for an ongoing garbage collection to block a concurrent build, we judge it to not be + * worth the extra complexity; assuming that the collection policy is not overly aggressive, the + * likelihood of a race condition is fairly small, and an affected build is able to automatically + * recover by retrying. */ public class DiskCacheClient {