openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christiaan <>
Subject Memory overhead by openjpa
Date Thu, 20 Dec 2007 14:55:09 GMT


I am doing some analysis for the memory usage since we are running into a
couple of problems in our project when doing import of large quantities of
objects. I’ve created a simple testcase which does the following:

1)	Create all objects (2 classes, one class with 5 string attributes, the
other is embedded and has no attributes);
2)	Call makePersistent() on the objects;
3)	Call commit();

The results:
-	After step 1) takes up 23 mb of memory in the testcase;
-	After step 2) the memory usage has increased to 191 mb. Actually there are
3 scenarios I used:
1)	Creating objects without the embedded class (which has no attributes,
just an empty class): 75 mb
2)	Creating objects with the embedded class instantiated: 180 mb;
3)	Creating objects with the embedded class instantiated and after
makePersistent() again instantiated (overwriting the previous value): 191 mb
-	During step 3) commit() the memory usage peaks at 580mb

1)	to persist objects which take up 23mb of memory, a total of 580mb so
giving a memory overhead of a factor 25 by the openjpa!
2)	maintaining the datastructure whether objects are persistent increases
the memory with a factor of 4 to 8, depending whether embeddable objects are
3)	“overwriting” embedded objects within a transaction, the previous
embedded object still seems to take up some memory;

I haven’t done a thorough analysis on this but some interesting things I
noticed from the profiler:
1) One of the hotspots is in storing the RowImpl._sql. If I am not mistaken,
this sql is stored (cached) for each object to be inserted. So in large
transactions where a lot of similar objects and modifications are involved,
this is quite a duplication which leads to unnecessary memory overhead. Of
course there is a performance gain of caching it, but may be this should be
better balanced with memory usage?;
2) Though I’ve set kodo.Log=none there is a hotspot in
LoggingConnectionDecorator? Is this decorator used for something else as
well or is this a bug? I removed it in code from DecoratingDatasource and
this reduced the total memory usage to 500mb

Comments are welcome.

Kind regards,

View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message