Memory usage for automation interface w/Java API

[Alan Dunn]

Is there a particularly good way of tracking the memory usage of EA when using the automation interface Java API? Currently, the size of the associated EA image grows and grows during the course of my program's run until the computer grinds to a halt, but the program should not be retaining any data from the Sparx model directly (the program retrieves a number of values from a model, makes copies of those values into its own structure, and then the parts of the model referenced within the program should fall out of scope and be collected). The memory allocation does not seem to decrease significantly after the run of the Java garbage collector either (which I checked using the java -verbose:gc option and monitoring the output). Is there any way I can see what information EA is keeping around, and perhaps gain any information as to why it thinks that information should stay around?

[mrf]

There are a few inherent weirdities at play here due to the nature of how Java interacts with COM.

1. The Java interface is simply a COM wrapper, with each of Java objects you aquire from EA containing a simple COM reference to a COM object on the EA side.
2. Because the Java objects only contain a 4 byte COM reference, the garbage collector will not prioritise it for garbage collection as it does not take up enough space to warrant the time taken to clean it up. The Java process itself is not taking up much memory (as it only contains a collection of references), therefore no garbage collection is performed.
3. On the EA side however an increasing number of COM objects will be building up, unable to be released and freed as their references are still being held on the Java side because the JVM's garbage collector is ignoring the small wrapper objects.

To quote from the ReadMe.txt found in the JavaAPI directory:

Due to the nature of Java interacting with native methods and COM, garbage collection is not optimal. Native COM classes and memory allocated for these are not seen by the Java garbage collector, so you should explicitly invoke a garbage collection from time to time when working with many objects using the Java API. This will ensure native memory is freed in a timely fashion.

The explicit garbage collection mentioned can be invoked by calling Repository.Compact() - a method only found in the Java API - which will explicitly force the JVM to garbage collect any of the COM references that have been marked for garbage collection. As is stated in the readme file, this should be performed regularly to avoid the build up of dead memory.

[Alan Dunn]

That worked. I had read that file, but I guess I didn't understand what it said. Thanks!