Go memory problems on WinXP

[cztomczak]

Binary example doesn't work anymore on WinXP after installing Windows Updates.

Issue reported to the Go project:

"Windows XP: "panic before malloc heap initialized" after installing Windows Updates"
https://code.google.com/p/go/issues/detail?id=7284

[cztomczak]

It turns out that Go requires 768 MB of continous memory space for its garbage collector to work on Windows. The largest block on XP is 2 GB. The problem is that libcef.dll is loaded in the middle of an empty memory space (due to ASLR security feature - Address space layout randomization). Thus the largest block of continous memory is 712 MB. See comment 15 in Issue 7284 for the result of debugging memory using VMMAP. See comment 19 by Alex Brainman in this same issue for more details about the whole problem.

Issue also reported on the CEF Forum:
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11481
See the comment 1 by Marshall in this topic:

Attempting to reserve almost 1/2 of available memory on a 32-bit system is bound to fail a lot. Address space becomes more fragmented as time goes on. I doubt any system that's been used for a few hours/days will succeed with this allocation.

What Go does with memory may cause problems on some systems. It doesn't seem to be limited only to 32-bit systems, as Go devs claim in Issue 7284. See comments 21 and 27 in that issue.

[cztomczak]

We can either of two things suggested by Marshall on the CEF forum:

1. Delay load libcef.dll so that Go can allocate its memory before CEF is loaded. Google "delay loading dll". Looks like something like LoadLibrary() should be used to load libcef.dll manually.
2. Don't use Go for the renderer processes. Use a normal helper exe with something like the message router instead.

[z505]

what happens if the render processes are made in C inside go and only C? Does go still start its runtime/link its runtime into the exe and the garbage collector and everything, if you just have a C program inside go and nothing else?

Still, even if you could trick go into not pulling in the garbage collector and make a C exe, it seems like kind of a hack and not really solving the issue. And, if you write a go program that is only C code, might as well just use GCC instead of go... but, with go using C, you at least can just compile it as usual with Go and not make a separate GCC/C file.

Apologies, I'm not familiar with C code inside Go code and what it creates exe/elf wise, as I have not studied it much yet. To summarize: is there a way to use C inside Go without pulling in the Go runtime/garbage collector.

[cztomczak]

CEF can run sub-processes (Renderer, GPU, etc) using a separate executable, thus C++ could be used to create such executable. Most of CEF API is available in the Browser process. There is some CEF API available only in the Renderer process like some handlers and callbacks and DOM API (limited), but this still can be exposed using IPC messaging. Currently CEF2go doesn't expose any Renderer process API, so it wouldn't make a difference whether sub-process is run using Go or C++.

Regarding essence of the issue, I don't think CEF2go should support Windows XP. Right now this OS has less then 5% usage share on desktop [1].

[1] https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers

[cztomczak]

Latest Chrome/CEF don't even support Windows XP / Vista anymore. So after upgrade to latest CEF it won't be possible to support this OS. So closing.