This program will hit an OutOfMemory error which will automatically generate a heap dump. The heap dump will be in a file with extension .phd. The name of this file will depend on the OS.

start the heap analyzer like so:

java -Xmx1200m -jar <path to ha jar>/ha450.jar

Choose File -> Open and select the heap dump file that you want to inspect.

Note that the summary shows the memory available to the jvm, the jvm version, and other interesting details.

Select the tab 'leak suspects'

Note: With Derby the 'page cache' is intentionally allocated ahead of time. This is almost always identified as a leak suspect and is a red herring, so the first leak suspect can be ignored:

33,729,032 bytes (53.69 %) of Java heap is used by 1,000 instances of org/apache/derby/impl/services/cache/ClockPolicy$Holder

Look at other leak suspects:

27,039,776 bytes (43.04 %) of Java heap is used by 842 instances of java/util/HashMap$Entry

Right click on this entry, and select 'Find object in tree view' from the menu.

You can see these are coming from 27,039,888 (43.04%) [72] 4 org/apache/derby/impl/store/access/BackingStoreHashTableFromScan 0x36c94b8,

This then gives us a suggested place to start looking at the source code.

In the case of DERBY-6096 the problem was that BLOB size was estimated at 0, and thus the memory usage needed by BLOBs was estimated as small, leading Derby to try to hold large objects in memory when trying to do a hash join