CEF Forum

Application: We have a Swing Application On Windows.

JRE: We use 32bit Jre7 and Hotspot in this appliction

Fuck me operation: We upgrade jcef from version_49 to version_95

Problem: The number of oom has increased a lot. 1% to 4%. It is not occur at cef. It occur everywhere when people use our application.

Problem Detail: threads 200+, memory 600M.
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1018)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Thank u very much

Have you tried increasing the JVM memory limit?

magreenblatt wrote:Have you tried increasing the JVM memory limit?

We have not tried this. The jvm -xms=900M.

Could u tell me the detail about this?

Thank u

Hi!

Increasing amount of -Xmx or -Xms has negative effects on how much memory the native part of the java process can access.
In Win32 the process has a fixed 2GB RAM process size, "-Xmx" tells the JVM to use this amount of memory (e.g. 1024m which is one half) for the java memory.
The native part then is the rest which has to be used for loading binaries (DLLs), executing binary logic (malloc,... in C code), creating java threads and so on.

So, increasing Xmx effectly reduces the memory available for creating new native threads!

We had similar problems and reduced them in that way:
1. Analyse how many Java ("xmx") memory your application really needs and set xmx accordingly.
2. Using the "-Xss" parameter reduces the standard initial memory every native thread gets allocated.
3. Load the CEFApp right after starting the application, this reduces the problems of loading big binaries fails because of native memory fragmentation.
fourth option (not implemented by us because of too many binary restrictions):
4. Change to 64bit JDK.