It seems that having "Publish fitnesse results report" post-build step in a job makes Fitnesse plugin produce huge amounts of hudson.plugins.fitnesse.FitnesseResults objects which have links and therefore are not being collected by GC.

After an empty Jenkins server startup there are no such objects:

$ ./jmap -histo 4324 | sort -n -k 2 -r | grep -E 'hudson.plugins.fitnesse.FitnesseResults$'
$

After I create a job that fetches a ready XML file with Fitnesse results (quite a big one: 2201 pages: 41 wrong or with exceptions, 0 ignored) and has a "Publish fitnesse results report" post-build step and run this job once, I get:

$ ./jmap -histo 4324 | sort -n -k 2 -r | grep -E 'hudson.plugins.fitnesse.FitnesseResults$'
  66:          2064          99072  hudson.plugins.fitnesse.FitnesseResults

After running it twice:

$ ./jmap -histo 4324 | sort -n -k 2 -r | grep -E 'hudson.plugins.fitnesse.FitnesseResults$'
  56:          4128         198144  hudson.plugins.fitnesse.FitnesseResults

And so on. Every other run adds nearly 2000 such objects.

Connecting to the process with jconsole and forcing GC run does not change the number of these objects at all. This is why I suggest all these objects still have valid links to them.

So, on large Jenkins installations with many jobs that analyze fitnesse results this leads to almost full heap memory consumption which in turn leads to frequent GC runs which results in Jenkins being unresponsive (we used to have 3sec GC runs every 3sec)