JabRef should release unused heap more frequently

[lenhard]

It seems that we have a memory leak with the entry editor on current master, latest commit 0326d77

JabRef 4.0-dev
Windows 7 6.1 amd64
Java 1.8.0_121

To reproduce:

• Open entry editor and select entry in the main table
• Press down key to cycle through the database
• Watch RAM consumption grow and not go down again

@JabRef/developers Please see if you can reproduce this on your system. This seems quite serious to me and a blocker for 4.0.

Any hints where this might come from are very much appreciated. @koppor Could you maybe try tracking this down with git bisect?

[lenhard]

@tobiasdiez I suspect that bindings are the cause of this all.

I know your time is limited, but can you please have a look at this? It's really a game changer...

[LinusDietz]

Confirmed. Had about 2.5GB allocated RAM after 5 minutes of clicking around in a Bibtex File with about 50 entries. Closing the EntryEditor did not help:/

JabRef 4.0-beta3
Mac OS X 10.12.6 x86_64
Java 1.8.0_144

[tobiasdiez]

The main reason for the memory leak is that the event listener in the source tab is never unregistered: https://github.com/JabRef/jabref/blob/master/src/main/java/org/jabref/gui/entryeditor/SourceTab.java#L55

After uncommenting this line, the memory still increases a bit for each new entry but not as much as before. I tried to further investigate the issue but couldn't really pinpoint the cause.

First of all, mostly int arrays are left over after opening a bunch of entries (the screenshot shows the difference in the memory consummation/allocated objects between a clean start and after the entry editor was opened for a few entries):

However, most of these arrays are actually no longer referenced and can be removed by garbage collection (no idea, why these are kept):

It appears that these numbers (and the other objects like HashMaps) have their origin in JavaFX. The bigger int arrays are a kind of raster image of older entry editors. Moreover, a few other objects are referenced by a cache in the JavaFX style manager (but again, these are weak hash maps).

Sorry, I don't have time to have closer look or even provide a fix. But I can definitely recommend the YourKit Java Profiler (see e.g. their documentation about memory leaks; license is in admin rep)

[lenhard]

@tobiasdiez Thanks for looking into this! I can confirm that the source pane is the most critical. Oh boy, I am happy that this was due to my changes, because it means that it's easy to repair.

#3116 repairs the event deregistration in the source tab. I would suggest the following: When #3116 is merged, the obvious blocker is gone and we can remove this issue from the 4.0 milestone. But we should keep investigated why the heap size doesn't really go down. After all, most of the heap reserved for JabRef is actually unused.

[LinusDietz]

I wonder if we could add some regression test that does the memory profiling automatically for us. Like selenium, just for java apps.

[lenhard]

Since the PR is merged, I've renamed this issue. Our main problem is not that JabRef consumes too much memory, but that it doesn't release unused heap. If there's a peak consumption, then JabRef somehow doesn't give memory back to the operating system when it's no longer needed.

EDIT: And since the memory leak is fixed, we can remove this from the 4.0 milestone.

[j0hannes]

I can confirm this issue with the 4.0-dev version. After using JabRef for a while, memory consumption goes up from 5.8% (start) to 18.1% and more. That's when I close and reopen it.