In short: open a JXRay report, go over the “red flags” in it, find the one(s) that will give you the biggest bang for the buck and change your code accordingly. Each JXRay report contains is a list of all possible problems / optimization opportunities, but in each heap dump a given problem may or may not cause much waste. So once you obtained a report, you should first find problems that cause maximum waste
Boxed numbers are objects such as java.lang.Integer, java.lang.Float etc. Each such object is allocated on the heap, contains all the standard internal “bookkeeping” data that the JVM needs, and therefore takes much more memory than its “payload” value. For example, a plain int number takes 4 bytes, but an instance of java.lang.Integer takes 16 bytes in most JVM implementations. Boxed numbers were introduced mainly to support “numeric” elements in collections such as ArrayLists or HashMaps.
Today we released JXRay 2.7u6. This version contains numerous usability improvements, some performance improvements and bug fixes, including, but not limited to: Faster and more accurate analysis of some Android heap dumpsBig HTML reports that JXRay may generate are now rendered much faster by browsersRetained memory reported for all objects. The “Where memory goes, by class” table can be sorted by any columnInstances of classes such as java.util.Date, java.lang.reflect.Method, java.math.BigInteger etc. are represented in user-friendly
If an app keeps sensitive data such as credit card numbers, passwords etc. in its memory, then its heap dump will contain that information as well. That creates legitimate concerns, especially at big companies: what if sensitive data leaks after we shared a dump with another team to facilitate debugging? Fortunately, JXRay is already much better than most other tools in this respect. First, as explained in one of our previous posts, it allows you
Our users sometimes try to analyze a big heap dump (say 30G) on a machine, typically their laptop, that has a much smaller RAM (say 8G). Unfortunately, for most heap dumps that doesn’t work: JXRay fails with an OutOfMemoryError. That’s sad but true: not just JXRay, but all tools for advanced heap dump analysis (Eclipse MAT, YourKit, VisualVM…) require, in the average case, the same amount of memory as the heap dump size, and preferably