Recently when profiling our server application for potential memory leaks using YourKit I encountered an "easy gotcha" to reduce the memory foot print for a core jdk class.
We utilize java.util.concurrent.CopyOnWriteArrayList as inner field, and sometimes (in fact for about 50% of our instances) these list is empty. COWAL stores its elements in an simple object array which has size zero for empty lists. But it does not use a single shared instance - every list has its own empty object array instance.
I never paid attention to the memory footprint of empty lists and it doesn't sounds like a big waste - just one object per instance. But in this memory dump this minimal waste summed up to 750 kB.
Ok, it was a giga byte dump, but nevertheless, too much to ignore!
java.util.ArrayList offers the same usage pattern. Even if this class is not used in our code at such a core point as COWAL the waste in this paricular dump also summed up to more than 500 kB. Certainly because this is a commonly used class in library code. I think if you dig further, you'll find more instances of this pattern in jdk classes.
Even if this can be "fixed" by using your own list implementations I'll vote for a fix in the jdk! It would be dead simple (just introducing a static final field with the immutable empty object array and share it between all empty list instances).
Perhaps if I find some time I'll provide a patch for open jdk.
Subscribe to:
Post Comments (Atom)
3 comments:
Thanks for the hint!
Note that ConcurrentHashMap has an overhead of about 2Kbyte (using the default constructor)!
Admittedly this could be a static field in the COWAL class but I do question the waste that you are in direct control of yourself - all those fields (objects size space!) referencing empty (not null) lists.
Maybe you should pay more attention to code. Original author propably choose COW list because it is thread safe and faster then synchronized list.
With ArrayList you safe 500kb and break app. Very good.
Post a Comment