791398 - Work around profiler OOM'ing on low-memory devices

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

+++ This bug was initially created as a clone of Bug #789667 +++

Bug 789667 is the "real" fix, but in the meantime we have developers and partners who need access to *some* profiler on b2g.  Upcoming patch will stop the bleeding.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Lower the default sample size to prevent OOMs

Comment 2

[Benoit Girard (:BenWa)]

Lowering the number of entries to 100,000 will give you ~500-2k samples with js enabled and no stackwalking giving a 0.5s-2s buffer at 1ms interval. I'm fine with this to make it usable but it's not really a solution since the buffer will be unusably small.

Is the crash only when saving the profile? If so we should just save to a file stream properly instead of building the whole string.

Comment 3

[Benoit Girard (:BenWa)]

Comment on attachment 661392 [details] [diff] [review]
Lower the default sample size to prevent OOMs

I don't object to landing this patch very temporarily if you're alright with the caveat I mentioned. I am a bit concerned that a profile with too little samples is just misleading and not statistically significant.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Another patch in this series bumps the sample interval to 10ms.  Without this patch, we crash 100% while trying to dump the profile.  I agree that the "real fix" is to stream the data, which is what bug 789667 covers.  But without this bandaid, the profiler is 100% unusable on b2g.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/integration/mozilla-inbound/rev/74408f5b036a

Comment 6

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/74408f5b036a