Since 1.485 Jenkins keeps lazy-loaded builds held via SoftReference. This is normally appropriate—you want to hold them as long as possible, but without exhausting the heap. Still, there are reasons why you would prefer a different strategy. If you are pushing up against heap limits, other lazy-loading bugs might cause Jenkins to repeatedly load and then drop build records, causing slow performance and lots of disk I/O. If you want to reproduce a lazy-loading bug, the unpredictability of soft reference GC complicates things. So there should be an option (I guess a system property) to control how a BuildRef holds its referent:

1. As a soft reference, as now.
2. Using a hard reference, never released. (This is not the same as pre-1.485 behavior since the first load is still lazy.)
3. A hard reference released after a certain amount of time has elapsed since the last time the reference was traversed.
4. A hard reference so long as the maximum number of such references is not exceeded (i.e. a LRU list).
5. Not held at all (just for testing behavior of initial load without actually needing to restart Jenkins).
6. Perhaps soft or weak variants of #3 and #4, i.e. initially a hard reference, then downgraded rather than released entirely.