[core] Jadx-gui consumes a lot of resources when decompilation is completely finished

[bagipro]

When I have an app opened in jadx-gui, battery of my laptop is flying away :D Probably it's a bug, and something continues consuming CPU resources

[skylot]

@sergey-wowwow can you check cpu usage using any profiler (like VisualVM)?
And if possible collect info about running methods (Sampler -> CPU for VisualVM).
Otherwise I can't reproduce this issue and even don't know where to start looking 😞

P.S. jadx hit 1000 issues! Yay! 😆 🎉

[bagipro]

@skylot
Hmm, by some reason Sampler -> CPU for VisualVM displays nothing. Monitor shows this

[skylot]

@sergey-wowwow
So CPU usage is 0.8% this can't 'fly away' your laptop 😄
Anyway, heap usage is strange, so many peaks is not good.
Which java version are you using? (check Overview tab). Latest java version is preferred.

[bagipro]

@skylot
That's true! 😂 If I leave it for e.g. 30 mins, the laptop will completely uncharge from 100% to 0% (however if I watch movies, it will uncharge within 8+ hours)

My Java version:

JVM: Java HotSpot(TM) 64-Bit Server VM (14.0.2+12-46, mixed mode, sharing)
Java: version 14.0.2, vendor Oracle Corporation
Java Home: /Library/Java/JavaVirtualMachines/jdk-14.0.2.jdk/Contents/Home

[skylot]

@sergey-wowwow can you try disable memory usage bar (View -> Show memory usage bar).
I see high cpu usage of javax.swing.Timer on macos even with empty action.
If disabling this bar will help I can replace timer with another, I just need confirmation that is main cause )
Ideally CPU Time for jadx process in Activity monitor must stop increasing.

[bagipro]

@skylot
Suddenly that happened!

[skylot]

@sergey-wowwow looks like my guess was not correct (
I tried different things, but can reduce cpu usage only sligtly.
Anyway, I disable this bar by default, so I hope it will not affect many users.

[raulsiles]

Hi @skylot. I can confirm I was suffering a significant CPU performance hog with jadx-gui (v1.1.0, where the memory usage bar was not disabled by default yet) in macOS using Java 14.0.1 (default version in macOS Catalina) while the GUI is displayed in the screen. By simply minimising the application, the CPU gets relaxed again...

I have tried disabling the memory usage bar, as suggested above, and the issue completely disappeared, so your hypothesis is correct in my case. As soon as I show the bar again, the CPU party re-starts... ;-D

[jpstotz]

@raulsiles Can you please check Jadx using VisualVM what thread is causing this?

In VisualVM open the tab "Sampler" and start data collection using the "CPU" button. On an totally idle Jadx no thread should be displayed. But as you encounter CPU usage you should see one or more threads that are consuming CPU time. If you have one ore more you can click on the plus sign before the thread name to expand the view and see what Java methods are currently executed.

If you could post this data this would be really helpful.

[raulsiles]

Hi @jpstotz:
Right after starting jadx-gui v1.1.0, with no activity from the user, as soon as I show the memory usage bar, the thread that consumes more CPU under VisualVM "Thread CPU time" tab is "AWT-EventQueue-0".

In the "CPU samples" tab however, the "Forward calls" display the Java methods in the attached images, with huge RMI TCP connection usage, and some AWT.

The CPU usage switches between the two RMI TCP connections threads after a few seconds, in an alternate way: one, and then, the other, and back to the previous one...

[jpstotz]

@raulsiles The RMI TCP connection should not be the problem source. They should be caused by VisualVM retrieving the JVM internal data periodically. What makes me wonder is that you observe two of them.

The version you used for generating this data is v1.1.0 or have you used the latest unstable version that already contains skylot's fixes?

[raulsiles]

Hi @jpstotz. Yes, I used on purpose v1.1.0 as this is the version I originally found the issue in.

AFAIK, the fix skylot introduced in v1.2.0 is to hide by default the memory usage bar to avoid this issue. I've tried with v1.2.0 and I can confirm the issue persists if you enable the bar back (if you need it, I can collect the CPU samples via VisualVM with the latest version).

[raulsiles]

@skylot I have double checked the CPU peaks are still prevalent in the latest build from Jan 15, 2020, jadx-1.2.0-b1479-a3ea5145, as soon as the view for the Memory Usage Bar is enabled. Perhaps this issue should be reopened to work on a future definitive fix for it (apart from the partial fix of hiding the Memory Usage Bar, that BTW works like a charm).

[jpstotz]

@raulsiles I am sorry but the last days I investigated this issue a bit deeper.

The most obvious effect of this issue is that using VisualVM on Jadx while the HeapUsageBar is active is that every second the heap usage increases by about 4 MB (at least on my test system).

To track down the cause I uncommented every piece of code in the class HeapUsageBar and ste-by-step reactivated it.
In the end I found out two problematic lines I would have never suspected to cause any trouble:

The first one was:

jadx/jadx-gui/src/main/java/jadx/gui/ui/HeapUsageBar.java

Line 34 in 707ed9a

private final transient FocusManager focusManager = FocusManager.getCurrentManager();

Don't ask my why, when this line is uncommented the CPU is active and the memory usage continuously rises.

The second line that activates this issue is:

jadx/jadx-gui/src/main/java/jadx/gui/ui/HeapUsageBar.java

Line 113 in 707ed9a

setString(update.label);

If the method setString(String) is called one time on the HeapUsageBar (which is effectively an extended JProgressPar instance) the issue starts. Please note that the issue has nothing to do with if and how often we update the information shown by the HeapUsageBar! Calling it once at the beginning is enough to trigger the issue until the component is hidden.

This brings me to the conclusion that there is nothing we can do to fix this problem. It is obviously a bug in Java. But the bigger problem is that there is no real workaround as setString is used to print the necessary information onto the JProgressBar. The only way would be to just show the progress bar itself without any further text printed on it.

[raulsiles]

Wow @jpstotz! Thanks for your really detailed analysis!

Based on your conclusions, if possible, then jadx-gui needs to get rid of the FocusManager, and replace the JProgressBar with another GUI Swing component (if it exists) not presenting that weird behaviour :(

I agree that not printing any text in the progress bar reduces its main purpose. Perhaps printing the string details only when you hover over or click in the progress bar could be another workaround.