Question

I’m focused on

• Derive architectural understanding of our Java application through footprint analysis
• Improve application performance by tuning memory footprint and optimizing Java collections and Java cache usage

For this purpose I ran a load test and analyzed a Java heap dump snapshots by using the Java heap analysis tool memoryanalyzer on our Java EE application which uses WebSphere application server v7.

I’m asking if the "Soft Reference Statistic" and "Weak Reference Statistics" can help for my goal, i.e:
to understand if we have a problem or there is something to fix ( or just improve ) in the application java code or in the configurazione of the application server.

advice to figure out how to figure out how to exploit these data would be greatly appreciated

Soft Reference Statistics

A total of 11.416 java.lang.ref.SoftReference objects have been found,
which softly reference 393 objects.
2.414 objects totalling 122,9 KB are retained (kept alive) only via soft references. No objects totalling 0 B are softly referenced and
also strongly retained (kept alive) via soft references.

Weak Reference Statistics

A total of 28.849 java.lang.ref.WeakReference objects have been found,
which weakly reference 11.663 objects.
132.437 objects totalling 7,4 MB are retained (kept alive) only via weak references. No objects totalling 0 B are weakly referenced and
also strongly retained (kept alive) via weak references.

Answer 1

First rule: Never use soft refereces. The guys a Sun who added that regret their decision, as they are useless and make GC more expensive.

Weak References are ok.

The question is: If you do need all that data in memory, trying to reduce the footprint will result in extra CPU, network or disk overhead, as you’ll need to store the data somewhere else.

How big is the heap of the app, that you need to make it perform better? And what is the maximum latency that you’re able to accept when GC kicks in? Have you tried tuning the GC?

---

Edit

Why never use soft references. Soft references are bad because

• They require 2 GC cycles to be collected. The first GC cycle marks them, and the second actually collects the memory. (this is not related in any way to the MarkSweep collectors)
• They are marked for collection after a full GC.

If you actually need the data held in the SoftReference, a cycle of load SF, full GC, load SF again, full GC will start, which is bad as it gets. The app potentially won’t crash because of an OOME, but it will be close to unusable.

Weak references are better, as they only cleared when they are "weakly" reachable, rather than when the app runs out of memory. The best (and only) example I know of a framework that uses weak references is Robotium (an android testing framework).