Closed Bug 969114 Opened 11 years ago Closed 11 years ago

MediaCacheStream wastes about 10% memory in allocation slop

Categories

(Core :: Audio/Video, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
mozilla30
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: bkelly, Assigned: bkelly)

References

Details

(Keywords: memory-footprint, perf, Whiteboard: [c=memory p= s= u=tarako] [MemShrink])

Attachments

(1 file)

DMD run on the poppit app on b2g v1.3 showed: Unreported: 108 blocks in stack trace record 1 of 424 3,981,312 bytes (3,579,552 requested / 401,760 slop) 8.08% of the heap (8.08% cumulative); 20.07% of unreported (20.07% cumulative) Allocated at replace_malloc /srv/mozilla-b2g28_v1_3/memory/replace/dmd/DMD.cpp:1247 (0x4006e74e libdmd.so+0x374e) malloc /srv/mozilla-b2g28_v1_3/memory/build/replace_malloc.c:152 (0x400feeba libmozglue.so+0x23eba) moz_xmalloc /srv/mozilla-b2g28_v1_3/memory/mozalloc/mozalloc.cpp:53 (0x4182aefe libxul.so+0x132aefe) mozilla::MediaResource::Create(mozilla::MediaDecoder*, nsIChannel*) /srv/mozilla-b2g28_v1_3/content/media/MediaResource.> mozilla::dom::HTMLMediaElement::InitializeDecoderForChannel(nsIChannel*, nsIStreamListener**) /srv/mozilla-b2g28_v1_3/co> mozilla::dom::HTMLMediaElement::MediaLoadListener::OnStartRequest(nsIRequest*, nsISupports*) /srv/mozilla-b2g28_v1_3/obj> nsJARChannel::OnStartRequest(nsIRequest*, nsISupports*) /srv/mozilla-b2g28_v1_3/modules/libjar/nsJARChannel.cpp:966 (0x4> nsInputStreamPump::OnStateStart() /srv/mozilla-b2g28_v1_3/netwerk/base/src/nsInputStreamPump.cpp:517 (0x40895d2e libxul.> nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) /srv/mozilla-b2g28_v1_3/netwerk/base/src/nsInputStreamPump.c> This shows that MediaCacheStream is wasting about 10% of the memory it actually requested in allocation slop. This is due to the 32KB MediaCacheStream::mPartialBlockBuffer member array. While it fits exactly in a power-of-2 allocation, the remaining member variables push it over into the next allocation size bigger. This could be solved by allocating mPartialBlockBuffer separately on the heap. This would be a minor win, but might be worth it given potential media use in games and other apps on b2g
No longer blocks: 965369
This moves the mPartialBlockBuffer to a separate heap allocation to avoid slop.
Attachment #8373155 - Flags: review?(cpearce)
Attachment #8373155 - Flags: review?(cpearce) → review+
Modest memory gains, but nom for 1.3t? since this is a low risk patch.
blocking-b2g: --- → 1.3T?
Pushed to b2g-inbound with messed up and then corrected commit log again: remote: https://hg.mozilla.org/integration/b2g-inbound/rev/76e72417a9d7 remote: https://hg.mozilla.org/integration/b2g-inbound/rev/b3150ee1da4d remote: https://hg.mozilla.org/integration/b2g-inbound/rev/b986786cf7dd Sorry for the botched land again!
Keywords: footprint
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
triage: low risk, take this for tarako. 1.3T+
blocking-b2g: 1.3T? → 1.3T+
Priority: -- → P1
Whiteboard: [c=memory p= s= u=][MemShrink] → [c=memory p= s= u=tarako] [MemShrink]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: