Memory inspections

See also Event inspections

Typical memory-related problems can be recognized with the help of the "Inspections" feature. Inspections enable automatic high-level analysis of application memory. Each inspection automatically detects a specific memory issue. Performing this type of analysis by hand would be a very complicated (if at all possible) task.

With the help of inspections you can easily find the causes and possible solutions of usual memory-related problems.

The "Inspections" view is added to any objects view, such as "Memory" or a tab representing a subset of objects. Inspections for all live objects (i.e. for the entire snapshot) are also available via top-level tab "Inspections'.

(1) To run all inspections as a batch use "Run All Inspections" button.
(2) To run a single inspection, select it in the tree and use "Run This Inspection Only" button (this is especially useful if you want to apply the changes made to an inspection's options).

All inspections are grouped by category:

• Memory waste: duplicate objects as a whole
  • Duplicate Strings
  • Duplicate Objects
  • Zero Length Arrays
• Memory waste: data duplication inside objects
  • Null Fields
  • Sparse Arrays
  • Sparse Primitive Arrays
  • Arrays with all the same elements
• Possible leaks
  • Leaked OSGi bundle class loaders
  • Objects Retained by Inner Class Back References
  • Thread local variables
  • Lost SWT Controls
• Other memory oddities
  • HashMap Hash Code Distribution
  • Highly Referenced Objects
  • Self Referencing Objects
  • Non-Serializable Objects Referenced from Serializable Objects
  • Objects With Biggest Distance To Nearest GC Root

Duplicate Strings

Find all java.lang.String's with identical text values.
Problem: Duplicate strings waste memory.
Possible solution: Share string instance via pooling or using intern().

Duplicate Objects

Find objects of the same class equal field by field, and arrays equal element by element.
Problem: duplicate instances waste memory.
Possible solution: reduce the number of instances by sharing, lazily creating, not storing permanently.

Zero Length Arrays

Find multiple instances of zero-length arrays of particular type.
Problem: Memory waste and additional load for garbage collector.
Possible solution: Use empty array per-class singleton e.g. via a static field in class.

Null Fields

Find instance fields with high percentage of 'null' values.
Problem: Possible memory waste.
Possible solutions: If some of the fields are not used, get rid of them rarely assigned fields can be moved to subclasses in the class hierarchy.

Sparse Arrays

Find arrays with big number of 'null' elements.
Problem: Possible memory waste.
Possible solution: Use alternate data structures e.g. maps or rework algorithms.

Sparse Primitive Arrays

Find arrays of primitive types with big number of 0 elements.
Problem: Possible memory waste.
Possible solution: Use alternate data structures e.g. maps or rework algorithms.

Arrays with all the same elements

Find arrays such that all their elements are the same.
Problem: possible memory waste.
Possible solution: use alternate data structures e.g. maps or rework algorithms.

Leaked OSGi bundle class loaders

Find OSGi bundle class loaders not associated with any current bundle revision.
Possible problem: such loaders, along with all classes they loaded, are likely memory leaks. They can appear if after unloading a bundle external references to its objects are left.
Possible solution: ensure your application leaves no references to bundle objects after the bundle is unloaded.

Objects Retained by Inner Class Back References

Find objects retained via synthetic back reference of its inner classes.
Problem: Such objects are potential memory leaks.

Thread local variables

Find thread local variables.
Possible problem: such objects are potential memory leaks.
Possible solution: clear thread local variables explicitly.

Lost SWT Controls

Find SWT control instances not accessible from shown UI.
Technically, it finds instances of org.eclipse.swt.widgets.Control which are not accessible from org.eclipse.swt.widgets.Display.
Problem: Possible memory leaks.
Possible solutions: Examine paths to lost objects to see if they really leaked

HashMap Hash Code Distribution

Find HashMaps with non-uniformly distributed hash codes.

To achieve good HashMap performance, hash codes of objects used as keys should be uniformly distributed. Otherwise, map access performance degrades due to hash collisions. The inspection finds HashMaps with entries most unevenly distributed among chunks.

Possible solution: consider better hashCode() implementation for objects used as keys, or use wrappers with properly implemented hashCode().

Highly Referenced Objects

Find objects referenced by a large number of other objects.
Possible problems: Incorrect relations between objects in memory, logical errors and/or non-optimal data structures.

Self Referencing Objects

Find objects with fields referencing 'this'.
Problem: Possibly incorrect logic and/or memory waste.
Possible solution: Remove redundant fields.

Non-Serializable Objects Referenced from Serializable Objects

If a class implements interface java.io.Serializable and one of its serialized fields refers to a non-serializable object (directly or through intermediate objects), java.io.NotSerializableException will be thrown in runtime on attempt to serialize an instance of this class. This inspection automatically detects such situations.

Which objects are inspected

You can inspect all objects implementing Serializable, selecting Inspections in the Memory tab, or only particular serializable objects.

For example, test whether HTTPSessions would have serialization problems (assume memory snapshot is open):

• Open all instances of HTTPSession in a new tab: use Memory | Instances by Class... (Ctrl+N), type "HTTPSession" and press Enter; "Include instances of subclasses" should be selected
• Click "Inspections" link in the tab
• Select "Non-Serializable Objects Referenced from Serializables" in the list and run it

Which objects are inspected

• Class can explicitly specify the list of its serializable fields with the help of static field serialPersistentFields
• Otherwise, instance fields without transient modifier are serializable

If a serializable class overrides writeObject(ObjectOutputStream) and readObject(ObjectInputStream) methods to change the default serialization behavior, it is impossible to automatically find out what fields will actually be serialized. Thus, the inspection can provide incorrect results for such classes. However, this should not be a big problem, because in most cases this only leads to "false alarms": the inspection would report a referenced non-serializable object which is not actually serialized by writeObject(ObjectOutputStream).

Please learn more about serialization in this article: http://java.sun.com/developer/technicalArticles/ALT/serialization/

Limitation

This inspection is only available for the profiler's own format snapshots, and is not available for HPROF-format snapshots.

The problem with HPROF snapshots is that they do not contain essential information needed for this inspection:

• It is unknown which classes are serializable, as there is no information about interfaces implemented by particular class
• It is unknown which fields are transient

The profiler cannot obtain missing data as the HPROF snapshots are produced by a JVM internal dumper which stores only fixed kinds of information.

Objects With Biggest Distance To Nearest GC Root

Find objects with longest paths to GC root.
Intention: helps finding longest chains of objects such as linked lists, queues, trees etc.