Leakage.
Wow.
After chasing a FeedTree memory leak for a solid week (actually longer if you count the time during the semester that I half-heartedly feinted at the problem), I’ve finally narrowed it down. It’s a bug in the way the finite entry caches interact with the replay defense mechanism, which tracks UIDs for very old entries; that tracking system keeps them alive long after they ought to have expired from the cache, eventually eating up all your memory with ancient news.
Fig. 1: Memory leak. Like the Price is Right cliffhanger, this graph of the app’s memory usage goes up and up and up, until you hear an awful crashing noise.
Now allow me to briefly hate on the Java runtime memory profiler (-Xrunhprof:heap=all) and HAT (heap analysis tool): Once I figured out that I needed to use them, figuring out how to get them to work correctly was almost as unpleasant as not having them at all. (Answer: update your entire system to J2SE 1.5, and then try the tools on your program 50 times; it will crash inexplicably for the first 49.)
This leads to Dan’s garbage collection lemma: It’s impossible in a GC system to leak objects by losing them. But if, rather than losing them, you merely misplace them, you are well and truly screwed without good heap analysis tools.