FAQ
Hi. You say the virtual memory Go reserves appears to be real memory,
how are you determining that?

When I experimented with the 32-bit port about six months back, I was
able to reserve nearly as much virtual memory as the device had
physical memory, which goes far beyond what iOS will actually give an
app. So I went with the assumption that mmap was working correctly on
iOS. If you have evidence otherwise I can look into it.

Thanks,

d.
On Wed, Jan 27, 2016 at 1:12 PM, wrote:
Hey all,

I'm investigating Go Mobile, and to start I'm looking at how the Go runtime
and GC behave inside of an iOS app. Some of my findings so far (correct me
if I'm wrong on any of these):

Unlike when a Go process runs directly within the OS, the memory it reserves
seems to be real memory and not virtual memory (none of it is considered
reclaimable), thus counting against the total memory for the process. This
means that if the Go GC reserves 300MB and the process is only allowed 400MB
before the OS kills it, then the rest of the process only has 100MB until
the Go scavenger frees up some memory.
The GC scavenger is reticent to return memory to the OS even if it's not in
use. It does happen sometimes, but seems unpredictable, and primarily when
GBs of memory are freeable.
The Go GC does keep some overhead available internally. If you deallocate,
then reallocate the same amount within the runtime it doesn't raise the
total resident memory of the process. (So, it works.)
Forcing a GC flush using `debug.FreeOSMemory` doesn't seem to do much.
Memory pressure within the process doesn't seem to change anything.

The first two items are of the biggest concern, as they mean that the Go
library could greatly increase the risk of out-of-memory (OOM) crashes for
an app. I assume this is related to the fact that the Go runtime is running
within another process and not talking directly to the OS. In testing on an
iPhone 6 Plus (1GB RAM), the threshold really was something around 400-450MB
of resident memory before the OS killed the app. Some possibilities I can
think of to remedy this:

Once memory is freed within the GC (but still reserved), mark it as
clean/reclaimable again. Virtual memory would stay the same, but resident
memory would drop. Not sure if this is possible.
Monitor for memory pressure (lots of info on iOS memory here) and respond by
scavenging. UIApplicationDidReceiveMemoryWarningNotification is an
asynchronous option, and
mach_vm_pressure_monitor/vm_page_free_count/vm_page_free_target may be
useful as well.
Scavenge more aggressively on mobile apps in general. Not sure what the
performance tradeoffs would end up being, but given that Go was generally
designed to work directly with the OS, and on desktop/server hardware that
allows swapping, this might be a reasonable tradeoff.


Are any of these options reasonable to ameliorate memory pressure caused by
Go's memory reservation? Are there others I'm missing? Is this something
that's on the roadmap to be investigated?

My test app is available here if it's helpful. It's useful for observing
some of the interaction between the Go runtime and the native runtime with
respect to memory.

Thanks!

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 10 | next ›
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 27, '16 at 6:19p
activeJan 28, '16 at 5:01p
posts10
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase