When would you let a reference strength cleared only under memory pressure size a cache, instead of an explicit bound?

## What you are actually delegating A reference strength cleared only under memory pressure occupies the rung between strong and weak: the collector keeps the target while there is room and clears it when there is not. Used for a cache, it looks like getting eviction for free. What it really does is hand the **eviction policy** — the single most consequential design decision in any cache — to a component that was built to answer a different question. A cache policy needs to know which entries are hot, how expensive each is to rebuild, how large each is, and whether one tenant is crowding out another. A collector knows one thing: how full the heap is. Those are not the same input, and no amount of tuning makes one into the other. ## What the collector knows, against what a policy needs | the policy needs | the collector has | |---|---| | recency or frequency of use | nothing; reachability is not use | | cost to rebuild an entry | nothing | | a target hit rate | nothing | | fairness across tenants or keys | nothing | | a capacity number to size against | only free heap, which changes constantly | ## The costs that arrive later - **Footprint expands to fill headroom.** The cache has no reason to stop growing until pressure arrives, so the steady-state live set is 'as much as the heap allows'. Capacity planning against that number is impossible, because it *is* the limit. - **Tracing cost rises with it.** Every retained entry is a live object the collector walks. A cache sized by the collector makes the collector's own work larger, which is a feedback loop, not a neutral trade. - **Eviction is a cliff, not a curve.** Clearing happens when memory is tight, which correlates with peak load. The service takes a cache-wide miss storm and a rebuild stampede at the worst possible moment, and the rebuild traffic itself needs memory. - **No number to reason about.** You cannot answer 'how much memory does this cache use' or 'what is its hit rate at steady state' in a review, because both are emergent. - **Portability is poor.** Ecosystems differ sharply: some offer this strength, some do not, and those that do differ in how aggressively they clear. A design that depends on the clearing policy does not travel. ## Where it is genuinely defensible 1. **A single-process tool, not a fleet service.** A batch job or a developer tool where a miss costs milliseconds, nothing else shares the heap, and nobody will ever page on it. 2. **Values that are pure and cheap to rebuild**, where the worst case of a mass clear is extra CPU and never a correctness or latency-contract problem. 3. **Entry sizes that vary by orders of magnitude**, where a count-based bound is meaningless and a byte-based bound would need a size estimator you do not have. 4. **As a second-chance tier beneath an explicit bound** — entries evicted from a bounded cache demoted to pressure-cleared strength, so they survive if there is room. This keeps the capacity story intact and uses the strength as an opportunistic bonus, which is the only shape that scales to a fleet. ## How to decide, and what to measure 1. Establish the **cost of a miss**. If it is a recomputation on the same machine, the strength is arguable. If it is a network call, a lock, or a tail-latency budget, it is not. 2. Establish whether a **bound exists that you can state**. If someone can write down 'at most N entries' or 'at most M megabytes' and defend it, write that instead — a stated bound is reviewable and a delegated one is not. 3. Measure **hit rate against size** with a bounded cache first. It is usually flat above some knee, and the knee is the bound. Finding it removes the whole argument for delegating. 4. If you still delegate, **measure the clear events**: how often the collector clears, how much it clears at once, and what the miss storm does to latency at the moment it happens. If nobody is watching those, the design is undefended. ## The position to argue in an interview The strong answer says this is not really a memory question but an ownership question: a cache whose size nobody owns has no capacity story, and a service without a capacity story cannot be sized, alerted on, or run by anyone who did not write it. The strength has a narrow legitimate use as an opportunistic extra tier, and a very common illegitimate one as a substitute for deciding how big the cache should be.