Enhancements for abnormal situations#2679
Conversation
| "-XX:+IgnoreUnrecognizedVMOptions", | ||
| "-Xms256M", | ||
| "-XX:MaxRAMPercentage=70.0", | ||
| "-XX:ParallelGCThreads=3", |
There was a problem hiding this comment.
Can you add details why this option is needed and how it works? (maybe link to an article with details)
Because from my perspective, a very heavy arguments needed to change GC defaults 🤣
There was a problem hiding this comment.
Oh, found your comment in issue.
Okay, if your tests show improvement, than it is fine, I think 🙂
There was a problem hiding this comment.
The G1GC (like other Java GCs) have one major drawback: if RAM/heap gets tight they have to perform a full GC run. A full run usually means that the whole JVM is suspended/paused (all Java threads don't execute any code) while the garbage collector is active. Of course a JVM that is paused can not react on user input which means that this state is extremely bad for interactive programs like UI programs or web servers as during the pause time no reaction to mouse/keyboard events happen or no HTTP requests can be processed. Modern GCs like G1GC thus try to minimize the pause time by using one GC thread per available logical core. It really looks impressive if you see a JVM on a server performing a GC on 128 cores in parallel, however if the JVM is running out of RAM the GC can not produce miracles. The GC CPU usage is constantly increasing but the size of the recovered heap is getting smaller and smaller.
As Jadx-CLI is not an interactive program keeping a balance between CPU usage by Jadx and the remaining OS is IMHO more important than a full GC run with maximum speed. Especially as the impact on Jadx of running G1GC on 3 or 8 cores is usually not very high.
Based on my observations Jadx the JVM makes use of the high number of GC threads when Jadx is already near death because of out of memory/heap, thus a situation where Jadx isn't working in a "normal state" and the user will most likely need to kill Jadx.
GC1GC limits the ration of GC cpu usage vs. program usage /there are also command-line args it change this), but I wasn't able to find a parameter/value combination that had an impact on Jadx. The heap usage by Jadx seems to be pretty unique so that the way the GC tries to detect heap saturation situations don't work with Jadx. May be this has something to do with catching OutOfMemoryError exceptions and continue processing?
Jadx-CLI: limit the maximum number of GC threads to 3
Jadx-Gui: Allow to disable the log output in the log viewer (e.g. in case of many errors)