views:

39

answers:

4

I want to reduce number of objects in memory. There may be many objects having same values. Is there way to find out all the objects which has same values in heap dump.

+1  A: 

Use profiler. I can say that YourKit has this functionality.

nanda
I cannot see any mention of that on their website, only a text search function for strings and arrays (only) in memory. If I understand correctly this feature would rely on an interner being integrated with the profiler.
finnw
+1  A: 

I want to reduce number of objects in memory. There may be many objects having same values.

I assume that your long term objective is to have your application save memory by keeping only one copy of objects that have the same value.

The problem with this idea is that you typically need to build / maintain an extra data structure so that you can find a previous object with the same value. For example, a HashMap. (Off the shelf solutions like the Guava interner are the same under the hood.) If you are not careful, this data structure may use more memory than you are saving by eliminating the duplicates.

Also, it not implemented properly, an "interning" data structure may effectively leak memory by preventing objects from being garbage collected. Solutions to the memory leak issue all involve using WeakReferences, etc at some level. And that means even more objects, and slower garbage collection. The latter is because 1) the interned objects need to be traced by the GC, 2) the interned objects tend to live longer and are more likely to end up in the old generation, and 3) the WeakReference instances are relatively expensive for the GC to deal with.

In summary, take care that you don't make your memory problems worse!

Stephen C
Using Interner from google guava is easier :)
nanda
@nanda - well yes, but you still need to be careful *where* you use it.
Stephen C
That's what profiler is for
nanda
@nanda - a profiler cannot predict whether interning will save memory.
Stephen C
but it can show you how many duplicates of an object you have, which is one information that can be used to determine whether you try the interning solution or not
nanda
A: 

Take a look at the Sun/Oracle Java implementation for the method Integer.valueOf(int i). It already has a pre-determined cache of popular values (from -128 to 127), so no new instances are created when calling that method for those values.

This shows that if you are careful in your creation of objects, then you can keep your memory footprint down. Perhaps you should investigate how your objects are being created and try to cache them at creation time. Perhaps by looking at popular use cases, or some profiling of the way the application behaves. This is going to be application dependent, and it is doubtful that there will be an out-of-the-box solution for you. I believe this will save you some effort in the long run, rather than trying to work out what is currently taking up too much room.

Noel M
A: 

I would approach it this way:

  1. Use a profiler to determine what classes are consuming the most memory
  2. For each of the top 5 or so immutable classes identified in step 1:
    • If it has a public constructor, make it private and introduce a public static factory method instead.
    • Implement hashCode and equals if you haven't already
    • Use an Interner to ensure the factory method always returns the same reference given the same property values.
  3. Profile again to see if introducing the Interner reduced your memory usage. If not then scrap the Interner and have the factory method simply call the constructor.

This will only work for immutable objects. It also depends how many copies of each object there are. If there are 100 copies of each object it will save memory, but if there are only 3 copies of each then it will not.

For very specific cases it can be worth rolling your own interner, e.g. when you have a finite number of possible values and a perfect hash function (like using instances of Point to represent squares on a chessboard.) Then you can use an array as the cache and there is no need for weak references.

finnw