Today I was charged with assessing memory leaks in this massive piece of software. For those of you that have never had the good fortune to run into a memory leak in Java, let me tell you they are clever foes.
First off, they hide under the assumption that Java doesn’t have memory leaks. Java has memory leaks, and they manifest when data structures (heaps, hashes, arraylists, etc) persist for long amounts of time and never get deleted or have any elements removed. The problem lies in the fact that a hash, for example, might hold some objects and then the program will go off and do other things. This causes that hash to sit there and hold it’s objects, giving the garbage collector the Dirty Squirrel when he comes around to free up that extra memory. If the system never comes back and annihilates said hash or the objects being held never get removed, the offending hash just sits there accruing memory until Doomsday comes to the virtual machine.
The first task is determining what data structures are sticking around and to what objects they belong. The step after that is figuring out what you can remove and when you can do it in order to prolong the lifespan of this software.
Right now I’m waiting on The Man to deliver my sharpened wooden debugging tool and silver-tipped load tester, until then I am learning about the ways of my enemy. When my tools arrive I will go in and cast out the demons of idiocy that plague this system.
Related Articles
No user responded in this post