Jabref: Entry editor produces constant load

[stefan-kolb]

When the entry editor is opened I experience constant high load from JabRef.
This needs to be evaluated and fixed!

When I close the entry editor load immediately goes down to idle.

[stefan-kolb]

It looks like JR is producing events? in such cases.
The classes that are created over and over are:
AccessControlContext, EventQueueItem, WeakReference
After some time the garbage collector kills all of them and the climb to the peak starts again.
@JabRef/developers What could cause this? We really need to find out...

What also causes constant memory increass is the creation of int[] but a lot slower than the rest of the problems and without CPU load.

Just clicking through the entries heavily increases the memory footprint and CPU load with open entry editor:

Actually removing a linked file causes the CPU leak. It is even enough to keep the General tab open as it seems...

Maybe the binding implementation has bugs?!

        BindingsHelper.bindContentBidirectional(
                files,
                text,
                LinkedFilesEditorViewModel::getStringRepresentation,
                this::parseToFileViewModel);

Unfortunately I could also cause the issue by just opening the entry editor and closing it again without doing anything else...
BUT clicking the general tab ALWAYS works immediately.

[stefan-kolb]

Maybe relevant: https://stackoverflow.com/questions/14558266/clean-javafx-property-listeners-and-bindings-memory-leaks

[stefan-kolb]

I just need to click tab titles and after a while the leak starts!

[tobiasdiez]

The EventQueueItem is an awt class while WeakReference is used for the JavaFX binding. Maybe, this memory/cpu leak happens because swing and javafx don't interact nicely? Does the same problems occur on the maintable beta branch?

Is there a way to find the code that generates these classes?

[stefan-kolb]

I couldn't find anything yet, also I'm not so much into these code parts.

[stefan-kolb]

I couldn't reproduce the constant load on the maintabl branch with a few tests yet, although I am experiencing this phenomen when cycling through the entries (memory spike/leak again):

[stefan-kolb]

Looks like AWT is creating InvocationEvents all the time:

java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=sun.awt.windows.WInputMethod$1@3eb272aa,notifier=null,catchExceptions=false,when=1527251549510] on org.jabref.gui.maintable.MainTable[,0,0,1896x8400,alignmentX=0.0,alignmentY=0.0,border=,flags=251658600,maximumSize=,minimumSize=,preferredSize=,autoCreateColumnsFromModel=true,autoResizeMode=AUTO_RESIZE_ALL_COLUMNS,cellSelectionEnabled=false,editingColumn=-1,editingRow=-1,gridColor=java.awt.Color[r=210,g=210,b=210],preferredViewportSize=java.awt.Dimension[width=450,height=400],rowHeight=25,rowMargin=0,rowSelectionAllowed=true,selectionBackground=javax.swing.plaf.ColorUIResource[r=0,g=120,b=215],selectionForeground=javax.swing.plaf.ColorUIResource[r=255,g=255,b=255],showHorizontalLines=false,showVerticalLines=false]

This is the runnable:

runnable=sun.awt.windows.WInputMethod$1@48d09dd6

Possibly related? http://mail.openjdk.java.net/pipermail/awt-dev/2018-January/013479.html

Looks like it is the case.

[stefan-kolb]

As far as I can tell this is a JVM bug and is fixed in 1.8.0_172 😢
Will keep an eye on this tho...

[stefan-kolb]

Maybe we should fix our Java version to 8u172 and up. Or at least warn the user?

[tobiasdiez]

depends a bit on how bad the leak is. If it makes JabRef/the system unusable we should set 172 as minimum. If its not that bad I would vote for ignoring it (we can always tell people to upgrade if they complain...)

[Siedlerchr]

I see no problem bumping the minimum version. Only the latest jdk is supported and often fixes security things.

[stefan-kolb]

For me this lead to my fan running on maximum all the time on my laptop.
And my machine isn't that old and slow.
I have no idea what this means for slower machines.

I'm not 100% convinced either, tho.