#1
|
|||
|
|||
Running into continuous garbage collection
Hi Folks,
I noticed that JDownloader2 is obviously running out of heap space and entering continuous garbage collection when adding many links. See the attached screenshot of visualgc that shows that situation. What puzzles me is, that the heap is not growing dynamically although OldGen is filled up completely and GC is not able to free any significant amount of heap space. Why is the heap space limited like that? How can the problem be solved? Platform: MacOS 10.12 Core: #37218 Launcher: #4018 AppWork Utilities: #2944 Browser: #37214 Updater: #37214 |
#2
|
||||
|
||||
heap is limited by the -Xmx start switch.
on my mac jd install, Oracle Corporation - 1.8.0_101(64bit) (39.15 MB/187.00 MB/455.50 MB) you will need to wait until Jiaz responds. He will provide a official answer.
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#3
|
|||
|
|||
Well, according to the JVM args shown in visualgc, there is no implicit limit set with -Xmx:
-Dfile.encoding=UTF-8 -Xms64m -Dsun.java2d.d3d=false -Dinstall4j.launcherId=5977 -Dinstall4j.swt=false -Dexe4j.moduleName=/Applications/jDownloader.app -Di4j.ownBundlePath=/Applications/jDownloader.app -Di4j.jreBundle=/Applications/jDownloader.app/Contents/PlugIns/jre.bundle If I add an -Xmx1g to the JVM args in Info.plist, the use case with the many links runs just fine. However, I suspect that this change will be overwritten by the next JD update again... |
#4
|
||||
|
||||
What is your used Java Version? Check about Dialog of JDownloader, it will show max heap size
We know that some java version have auto heap sizing issues when specifying low Xms values. You can easily remove the Xms and use Xmx matching your use case. Memory usage highly depends on number of links in JDownloader and what hosts those links are from. So yes, adding -Xmx1g will help in your case. JDownloader does only modify plist file if max heap is lower than 512mb. So you are safe to modify it
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
Java Version? Well, it's the one embedded into JD...
Looks like a rather ancient 1.7... Any advice how to use the system-java (1.8)? Maybe that resolves the not-growing-heapspace-problem alltogether... |
#6
|
||||
|
||||
remove/rename the provided jre directory
if you take screen shot before and after of the about window, you/we should get some references raztoki
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
#7
|
|||
|
|||
Well, (re)moving the Contents/PlugIns folder obviously results in using the system-provided java:
JVM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14, mixed mode) Java: version 1.8.0_92, vendor Oracle Corporation Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home/jre I'll watch that closely how heap-space behaves with that JVM... Will this change survive future updates? |
#8
|
||||
|
||||
update system doesn't actually maintain the provided java for memory.
its packaged/provided with the installer in your case the .app (not installed to the system) raztoki
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
Thread Tools | |
Display Modes | |
|
|