BiglyBT not responding after Java memory running low, GC?

[JBitte]

I've been experiencing a problem where Java memory is exhausted, and BiglyBT fails to respond to mouse clicks and I need to exit BiglyBT with the X in the upper right of the window.

I'm on Windows 11, and run via batchfile java command line:
java -Xmx1g -classpath BiglyBT.jar;swt.jar;commons-cli.jar -Dazureus.config.path=F:\BiglyBT-F com.biglybt.ui.Main

I took some optimisations from this link to bring my -Xmx beyond 1GB to -Xmx16050m and configure GC as described,
https://www.reddit.com/r/BiglyBT/comments/198n6yt/fyi_generational_zgc_is_awesome_for_my_bigly/

The above has been my environment ahead of any troubleshooting. I've been running BiglyBT beta jars.

I followed the error msg links of Diagnostic logs & BiglyBT disappears

looking at Diagnostic logs, I found "SWTError: No more handles" in 1735872392860_debug_1.log

[03:36:08] org.eclipse.swt.SWTError: No more handles
at org.eclipse.swt.SWT.error(SWT.java:4915)
at org.eclipse.swt.SWT.error(SWT.java:4804)
at org.eclipse.swt.SWT.error(SWT.java:4775)
at org.eclipse.swt.graphics.GC.drawIcon(GC.java:1116)
at org.eclipse.swt.graphics.GC.drawImage(GC.java:1005)
at org.eclipse.swt.graphics.GC.drawImage(GC.java:937)
at com.biglybt.ui.swt.Utils.drawResizedImage(Utils.java:3371)
at com.biglybt.ui.swt.columns.torrent.ColumnThumbAndName.cellPaint(ColumnThumbAndName.java:420)
at com.biglybt.ui.swt.views.table.impl.TableCellSWTBase.invokeSWTPaintListeners(TableCellSWTBase.java:444)
at com.biglybt.ui.swt.views.table.impl.TableCellSWTBase.doPaint(TableCellSWTBase.java:1374)
at com.biglybt.ui.swt.views.table.painted.TableRowPainted.swt_paintCell(TableRowPainted.java:810)
at com.biglybt.ui.swt.views.table.painted.TableRowPainted.swt_paintGC(TableRowPainted.java:479)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted.swt_paintCanvasImage(TableViewPainted.java:1839)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted.swt_updateCanvasImage(TableViewPainted.java:2846)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted.swt_updateCanvasImage(TableViewPainted.java:2817)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted.swt_calculateClientArea(TableViewPainted.java:2776)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted$RedrawTableRunnable$1.runWithDisplay(TableViewPainted.java:255)
at com.biglybt.ui.swt.utils.SWTRunnable.run(SWTRunnable.java:37)
at com.biglybt.ui.swt.Utils.execSWTThread(Utils.java:2003)
at com.biglybt.ui.swt.Utils.execSWTThread(Utils.java:2169)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted$RedrawTableRunnable.runSupport(TableViewPainted.java:263)
at com.biglybt.core.util.FrequencyLimitedDispatcher$1.runSupport(FrequencyLimitedDispatcher.java:68)
at com.biglybt.core.util.AERunnable.run(AERunnable.java:42)
at com.biglybt.core.util.FrequencyLimitedDispatcher.dispatch(FrequencyLimitedDispatcher.java:143)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted.redrawTable(TableViewPainted.java:3478)
at com.biglybt.ui.swt.views.table.painted.TableViewPainted$18.focusLost(TableViewPainted.java:1654)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:147)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4209)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1043)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1067)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1048)
at org.eclipse.swt.widgets.Control.sendFocusEvent(Control.java:2956)
at org.eclipse.swt.widgets.Widget.wmKillFocus(Widget.java:1855)
at org.eclipse.swt.widgets.Control.WM_KILLFOCUS(Control.java:5183)
at org.eclipse.swt.widgets.Canvas.WM_KILLFOCUS(Canvas.java:421)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4794)
at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:340)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4938)
at org.eclipse.swt.internal.win32.OS.PeekMessage(Native Method)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3621)
at com.biglybt.ui.swt.mainwindow.SWTThread.(SWTThread.java:526)
at com.biglybt.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:58)
at com.biglybt.ui.swt.Initializer.(Initializer.java:183)
at com.biglybt.ui.swt.UI.takeMainThread(UI.java:162)
at com.biglybt.ui.Main.main(Main.java:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.biglybt.launcher.Launcher$1.run(Launcher.java:48)
at java.lang.Thread.run(Unknown Source)

[03:36:08] [stderr] DEBUG::Fri Jan 03 03:36:08 CET 2025::com.biglybt.ui.swt.columns.torrent.ColumnThumbAndName::cellPaint::442:
[03:36:08] [stderr] invokeSWTPaintListeners (TableCellSWTBase.java:444), doPaint (TableCellSWTBase.java:1374), swt_paintCell (TableRowPainted.java:810), swt_paintGC (TableRowPainted.java:479), swt_paintCanvasImage (TableViewPainted.java:1839), swt_updateCanvasImage (TableViewPainted.java:2846), swt_updateCanvasImage (TableViewPainted.java:2817), swt_calculateClientArea (TableViewPainted.java:2776), runWithDisplay (TableViewPainted.java:255), run (SWTRunnable.java:37), execSWTThread (Utils.java:2003), execSWTThread (Utils.java:2169), runSupport (TableViewPainted.java:263), runSupport (FrequencyLimitedDispatcher.java:68), AERunnable.run, dispatch (FrequencyLimitedDispatcher.java:143), redrawTable (TableViewPainted.java:3478), focusLost (TableViewPainted.java:1654), handleEvent (TypedListener.java:147), sendEvent (EventTable.java:89), sendEvent (Display.java:4209), sendEvent (Widget.java:1043), sendEvent (Widget.java:1067), sendEvent (Widget.java:1048), sendFocusEvent (Control.java:2956), wmKillFocus (Widget.java:1855), WM_KILLFOCUS (Control.java:5183), WM_KILLFOCUS (Canvas.java:421), windowProc (Control.java:4794), windowProc (Canvas.java:340), windowProc (Display.java:4938), PeekMessage (OS.java:-2), readAndDispatch (Display.java:3621), (SWTThread.java:526), createInstance (SWTThread.java:58), Initializer
[03:36:08] [stderr] org.eclipse.swt.SWTError: No more handles

for BiglyBT disappears ( https://wiki.biglybt.com/wiki.php?q=Vuze_disappears ) and Vuze_disappears ( https://wiki.vuze.com/w/Vuze_disappears ), I recall the old vuze/azureus days and the vuze_disappears scenarios, and followed
#1270 and deleted the BiglyBT Java folder to avoid versioning issues

From the SWTError: No more handles find, I then went down the rabbithole of -> Finding SWT Leaks with Sleak, but I'm not a developer so I gave up.

SWT then suspiciously has become an issue, and BiglyBT may not be able to compensate for a No more handles problem, but it does degrade BiglyBT performance.

Another possible related issue is -Xmx16050m being exhausted.

I don't have a log from when performance is degraded, but Tools / Startup & Shutdown, JVM memory usage history shows on startup:
[12:16:45] : cpu: Keep-Alive-Timer=0%, mem: max=910.50 MB, alloc=176.50 MB, free=102.80 MB
[12:16:55] : cpu: Main Thread=22%, mem: max=910.50 MB, alloc=541.00 MB, free=351.20 MB
[12:17:05] : cpu: Main Thread=13%, mem: max=910.50 MB, alloc=540.50 MB, free=158.37 MB
[12:17:15] : cpu: Main Thread=10%, mem: max=910.50 MB, alloc=545.00 MB, free=169.53 MB
[12:17:25] : cpu: Main Thread=16%, mem: max=910.50 MB, alloc=544.50 MB, free=95.86 MB
[12:17:35] : cpu: SWT Thread=10%, mem: max=910.50 MB, alloc=693.50 MB, free=385.71 MB
[12:17:45] : cpu: SWT Thread=34%, mem: max=910.50 MB, alloc=667.50 MB, free=242.27 MB
[12:17:55] : cpu: SWT Thread=17%, mem: max=910.50 MB, alloc=697.50 MB, free=131.67 MB
[12:18:05] : cpu: SWT Thread=15%, mem: max=910.50 MB, alloc=700.50 MB, free=116.57 MB
[12:18:15] : cpu: DiskAccessController:dispatch(core/read)[0/0]=7%, mem: max=910.50 MB, alloc=884.50 MB, free=312.90 MB
[12:18:25] : cpu: DiskAccessController:dispatch(core/read)[0/0]=8%, mem: max=910.50 MB, alloc=885.00 MB, free=350.75 MB
[12:18:35] : cpu: DiskAccessController:dispatch(core/read)[0/0]=8%, mem: max=910.50 MB, alloc=889.00 MB, free=313.04 MB
[12:18:45] : cpu: I2PHelperSocksProxyConnect 32=7%, mem: max=910.50 MB, alloc=890.00 MB, free=338.66 MB
[12:18:55] : cpu: AEThread2:parked[9]=8%, mem: max=910.50 MB, alloc=894.00 MB, free=372.06 MB
[12:19:05] : cpu: DiskAccessController:dispatch(core/read)[0/0]=8%, mem: max=910.50 MB, alloc=894.00 MB, free=395.05 MB
[12:19:15] : cpu: AEThread2:parked[12]=9%, mem: max=910.50 MB, alloc=892.00 MB, free=423.43 MB
[12:19:25] : cpu: Tracker Announce Public Timer 1736=9%, mem: max=910.50 MB, alloc=880.00 MB, free=434.84 MB
[12:19:35] : cpu: AEThread2:parked[11]=8%, mem: max=910.50 MB, alloc=880.00 MB, free=218.61 MB
[12:19:44] : cpu: AEThread2:parked[10]=7%, mem: max=910.50 MB, alloc=875.50 MB, free=457.80 MB
[12:19:56] : cpu: DiskAccessController:dispatch(core/read)[0/0]=9%, mem: max=910.50 MB, alloc=875.50 MB, free=247.83 MB
[12:20:06] : cpu: DiskAccessController:dispatch(core/read)[0/0]=8%, mem: max=910.50 MB, alloc=884.50 MB, free=295.22 MB
[12:20:16] : cpu: DiskAccessController:dispatch(core/read)[0/0]=8%, mem: max=910.50 MB, alloc=835.00 MB, free=372.14 MB
[12:20:26] : cpu: AEThread2:parked[35]=19%, mem: max=910.50 MB, alloc=835.00 MB, free=324.07 MB
[12:20:36] : cpu: DiskAccessController:dispatch(core/read)[0/0]=19%, mem: max=910.50 MB, alloc=835.00 MB, free=241.39 MB
[12:20:46] : cpu: Tracker Announce Private Timer 3=3%, mem: max=910.50 MB, alloc=886.00 MB, free=440.02 MB
[12:20:56] : cpu: SWT Thread=5%, mem: max=910.50 MB, alloc=886.00 MB, free=360.02 MB
[12:21:06] : cpu: SWT Thread=4%, mem: max=910.50 MB, alloc=886.00 MB, free=283.37 MB
[12:21:16] : cpu: SWT Thread=3%, mem: max=910.50 MB, alloc=886.00 MB, free=235.18 MB
[12:21:26] : cpu: ConnectDisconnectManager=1%, mem: max=910.50 MB, alloc=847.50 MB, free=379.68 MB
[12:21:36] : cpu: PeerControlScheduler=0%, mem: max=910.50 MB, alloc=847.50 MB, free=328.12 MB

Here I thought the fancy GC switches would compensate for any degraded Java memory issues, as it is the host of BiglyBT. When looking in folder F:\BiglyBT-F\logs\save , there were no logs that seemed to cover Java GC operations.
I then configured for Java 1.8 in my java.vmoptions file:
-XX:+PrintGCDetails -Xloggc:f:\torrents-backup-\logs\gc.log

I ran with this option for some hours but no events were written. This makes me wonder if GC is actually invoked?
I will reboot and try again to see if GC.log populates. I know this is not a BiglyBT issue either, but maybe some guidance as other BiglyBT devotees would benefit.

My GC switches in java.vmoptions file:
-XX:-UseG1GC
-XX:+UseZGC
-XX:+ZGenerational

As a summary:
-Mouse clicks unresponsive. e.g. to "File / Transfers" not working when BiglyBT performance degrades
-SWT No more handles, probably the culprit to UI issues
-Java memory at limit, when does GC kick in?

[parg]

You run out of handles you're generally screwed. I don't see any evidence of you running out of JVM heap. Handles are used for SWT UI components as well as other OS resources such as file/network connections. So if you open a zillion files you can trigger handle issues (for example)

This is why there is the "Options->Files->Performance Options: Maximum files opened for read/write
[0: unlimited]" option for example

[parg]

TaskManager has columns you can add under the "Details" tab for "handles", "user objects", "GDI Objects", might be of use