Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19400

Configurable retention system for lazy-loaded build references


      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.

            jglick Jesse Glick
            jglick Jesse Glick
            2 Vote for this issue
            6 Start watching this issue