http://bugs.winehq.org/show_bug.cgi?id=58805
Bug ID: 58805 Summary: Chrome Embedded Framework CEF Massive Memory usage Product: Wine Version: 10.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: johnpgoodman@gmail.com Distribution: ---
Created attachment 79459 --> http://bugs.winehq.org/attachment.cgi?id=79459 memory usage
I noticed that recent versions of Logos Bible software make much more use of CEF and so each panel starts up a new process. I'm sure this is true of lots of other apps too. But the problem is on Mac or Windows CEF is very memory light but for some reason each process uses about 250mb of ram on wine. I've investigated this a little and grok suggests that the problem is likely this:
Chromium Embedded Framework (CEF) apps like Logos Bible Software spawn multiple renderer processes (~1 per UI panel). On Windows/Mac, each uses 20-50MB RAM by sharing V8 JIT code, Skia graphics caches, and fonts across processes. In Wine on Linux, unshared per-process duplication inflates this to 250MB/process, exhausting RAM with 10+ panels (2.5GB+ total). Root causes: Wine's ntdll doesn't share executable pages; D3D11 re-translates shaders per-process; emulated sandbox adds overhead.
It recommends a solution: 3 targeted patches to emulate native sharing: Shared V8 JIT Cache (ntdll/unixlib.c): Map V8's 128MB executable region to /dev/shm once per prefix. Unified Skia/ANGLE Cache (d3d11/utils.c): Global /tmp/wine-angle-cache for shader translations. CEF Sandbox Bypass (Launch flag + winevdm.c): Skip emulated sandboxing.
And points out that All Wine CEF Apps would be affected e.g. Discord, VSCode, Steam etc so many 1000s of users.
I haven't a great deal of expertise but I've a good track record of working with devs to do testing and builds etc to help patches through. I'd be very grateful for any assistance from a dev with this issue! thanks