Hi!
I just found this thread and wanted to reuse it, because it has the same goal, also we already discussed a similar topic here:
viewtopic.php?f=17&t=14829As we use JCEF, the JCEF/CEF binaries are all loaded in Javas native memory.
Our environment is as following:
JCEF version 3.2704
jdk1.8.0_60 32 bit
Windows 32 bit process
As far as I understand the native memory, all DLLs used for or chromium integration are loaded there, including the 58MB libcef.dll
We have the problem at our customer, that sometimes the native memory is that hard fragmented, that we can't even get those 58MB memory at once:
- Code: Select all
java.lang.UnsatisfiedLinkError: C:\systema\mpa_khbra\bin\win_x32\libcef.dll: Für diesen Befehl ist nicht genügend Speicher verfügbar
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.cef.CefApp.<init>(CefApp.java:152)
at org.cef.CefApp.getInstance(CefApp.java:247)
at at.co.systema.ui.controls.UIWebBrowserCEF.initCEF(UIWebBrowserCEF.java:75)
at at.co.systema.ui.controls.UIWebBrowserCEF.<init>(UIWebBrowserCEF.java:59)
Is there a chance to make this libcef.dll smaller?
Since this is a java speciality and a hard limitation on 32 bit processes, wouldn't it be good to keep the native overhead on a minimum?
Just loading a small jcef/cef.dll that starts a native process using the real big DLLs? Just thinking, knowing that will not happen - a whole process model change...
Unfortunatly we can't use less XMX and we can't use 64 bit JDK because of other DLLs we need to load.