Issue #2460: Objects are not garbage collected

Hello,

we've encountered a problem in our tool that eventually causes a GC Overhead / out of memory error:

We import structures called "FormalRequirements" that in turn contain entities called "NormalizedAccessPathImpl" (and InterfaceObjects). Each FormalRequirement is imported in its own transaction and the transactional context is being closed after the FormalRequirement is imported. However, we can see that over time more and more NormalizedAccessPaths clog up the RAM and won't be released. 

Below is the reference graph for them. Normally we would expect to see some service or helper class which accidentally holds references to those. But here we have only WeakReference ObjectDB stuff, DetachedTracker ObjectDB stuff, and more NormalizedAccessPaths or InterfaceObjects (which just seems to be go in circles).

We have tried to use the "purge" flag from https://www.objectdb.com/issue/2302, but without any improvement.

Do you have any ideas or insights, why the Garbage Collector won't be able to remove these objects?

Thanks,

Toby

It is unclear from these images if there are paths of strong references from root objects (which cannot be released by the GC). Can you share a full heap dump after GC that demonstrates the issue?

Thank you for sending the heap dump.

Are you using build 2.8.0_04? Can you check if this is a regression issue, i.e. if there is a an older release of ObjectDB (e.g. from a year or two ago) with which the memory is released in this specific case?

The heap dumps shows that there is one UnitOfWorkContext instance that strongly references many other instances of your classes (e.g. FormsatRequirementAddEvent, EventDataMap, CodeFunctionCallMergedImpl, CodeInterfaceObjectMergedImpl, NormalizedAccessPathImpl, etc.)

Apparently that UnitOfWorkContext  holds many entity objects in memory. If this is the case then it doesn't look as an ObjectDB issue. Try to break that large graph of objects so it will not be hold in memory by the JVM.

Thank you very much for the analysis. This is very helpful! We are discussing this topic right now and it seems that indeed the UnitOfWorkContext may be the cause. We'll investigate this further.

Thanks,

Toby

We can now verify that this is indeed an issue with the UnitOfWorkContext, so not an ObjectDB issue. Thanks again. Can be closed.