So, I got this idea to write some code that can automatically detect and point to potential memory leaks in testing, and I just wanted to see if my idea is reasonable before I go through the trouble of implementing it.
Essentially, a memory leak is defined as an increasingly large number of unused references. In Java, this danger is lessened significantly, compared to C++, because we're in no danger of dangling pointers, or forgetting a delete(), etc.
So this limits the ways that we can have a memory leak in Java. We can have a static reference to an Object, or we can have local references in a currently running thread, and that's about it, right?
My idea then, is to write a routine that looks through all the known project class files, and pull out all the static references. A reference then needs to be "recursed" down, and all the instance references it has need to be counted up. An object reference takes some amount of memory, and primitives take some amount of memory, and we can tally all that up. You could trigger this routine once, to get a baseline, then do the thing that you think is causing a memory leak, then run the routine again, and compare results. A delta threshold could be set, and then you could manually determine which objects got bigger purposefully, and which objects got bigger, but shouldn't have.
This is a test tool, of course, however, in the projects I work on, often times I am only able to reproduce these errors in production, with lots of users, so using a real profiler isn't always an option. Having this built in would save from having to actually run a profiler, and would allow for normal operation most of the time, except when diagnosing an issue on the production product.
The only issue I see, is that local variables in a currently running thread won't be accessible this way, however, knowing that limitation, one could require the code register these local (but long term references) with the test class itself, which would hold weak references to those objects in a static variable, thereby allowing the references to be counted.
Garbage collection would be an issue, so basically, I would "force" garbage collection by creating an unreferenced object, which overrides finalize to notify my thread when it is collected, which would then cause my GC detector to stop blocking, and then run the leak detector.
So, my question is, does this sound plausible? Do you think this would yield useful results?
