Memory leak in "Tenured Generation" heap (JVM 1.5)?!

Question

For about over a year, I'm trying to hunt down the memory leak in our server application. But after all the improvements I've made (especially with 'forgotten' listeners that didn't exist anymore), I'm confident that the application doesn't have a memory leak anymore. At least the new "jconsole.exe" tool of JDK 1.5 shows me a very intersting behaviour:
Even if the server app is doing nothing than one thread polling a database table for possible new jobs to process, the memory slightly increases over time ... very slightly. It's just like the screenshot at
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html#memory
where you might find a very slight tendency up. I run jconsole the whole day to track the application on a computer where no jobs got processed, so the application only sit there there whole day and just one thread has a loop that polls a database table via JDBC and doesn't get a result. The result is, that the memory chart is like the chart in the screenshot of the link above just with much more jaggies. About every 20 minutes, garbage collection seems to kick in, as the jaggie line drops about several megabytes just to increase again slowly.
Of course the thread loop creates objects but it doesn't hold any (debugged it several times and it is quite easy code). So this behaviour makes sense. But it doesn't make sense that the memory usage overall slowly increases over many hours (ultimativaly leading to an OutOfmemoryError).
So far, I still thought, it must be a memory leak in my application. But then, I played with jConsole and noticed this: if I just display the Memory Pool "Eden Space", the jagged line always drops down to the same level, i.e. no memroy leak. The "Survivor Space" is also constant in average (no memory leak). But the "Tenured Generation" line shows this memroy leak behaviour (slowly increases). This space is described as:
Tenured Generation (heap): pool containing objects that have existed for some time in the survivor space.
So, I'm not so sure anymore if this memory must be in my application. Unfortunately, jConsole doesn't show some kind of object tree that can be browsed and I would see what kind of object (collection) increase.
I tried profiling my application, but the profiled app runs so slowly that it would need many days or weeks until it's possible to identify some bad objects.
Is there another way to identify such memory waisters?

Answer 1

Write a main() that does the polling in a tight loop 1000 times. Then System.gc(); Thread.sleep(1000); System.exit(). Run the thing with -Xrunhprof. Observe the "live bytes" and "live objs" columns in the generated java.hprof.txt file. Anything that strikes as suspicious? If every polling round leaks one object, there's likely to be 1000 (or N*1000) of something live. Make sure the leak is in the polling routine by running it 1,000,000 rounds and getting an OutOfMemory.