Today, I needed to track down memory hogs in my ADAMS workflow framework. Thanks to jmap, I knew what objects of type weka.core.Instances were the culprit, I just didn’t know where. Manually looking through the obvious candidates didn’t uncover anything obvious.
The sizeofag library is extremely handy for calculating the size of objects, but didn’t allow me to inspect operators by themselves, ignoring their sub-operators. Hence I spent some time introducing a simple filtering mechanism to the library, which allows you now to skip objects, fields and classes in the class hierarchy of an object.
Once I added a menu item to my Flow editor in ADAMS, I could quickly check the size of the operators, homing in on the culprits. The fix involved a single line in two operators…
Oh, well, problem is solved now and I should be able to find memory hogs much quicker in the future. 🙂