The main question is whether there is a leak, whether you do not have enough RAM allocated, or whether you are not flushing out the connection.  There are no known memory leaks as of my last involvement with jdbm.  You can use a profiler to figure out the root objects that are causing those objects to be pinned and then figure out whether the transactions are not being properly committed or whether there is a real leak.  Remember that any hard references you might hold to jdbm objects  could cause them to be maintained beyond their intended life cycle.

Just to be clear, are you working on the JDBM v1.0 code [1], or on the fork labeled JDBM3 at [1]?



From: Dan Gravell <>
Reply-To: "[jdbm:discussion]" <>
Date: Thursday, January 23, 2014 6:22 AM
To: "[jdbm:discussion]" <>
Subject: [jdbm:discussion] OOME due to large numbers of dirty BlockIos in RecordFile

Darn... I rebooted and the heap dump was in /tmp...

The heap size was 128MB. From memory, the RecordFile was consuming about 70MB. There were several thousand BlockIo objects, with the largest about 8KB and going down from there...

Sorry, I can re-run the test to recreate the heap dump if you need more accurate figures. It just takes several hours...

OOME due to large numbers of dirty BlockIos in RecordFile

Sent from because you indicated interest in

To unsubscribe from further messages, please visit