Bug 69778 - WebProcess was using 7GB RAM after playing with some WebGL/WebAudio demos
Summary: WebProcess was using 7GB RAM after playing with some WebGL/WebAudio demos
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.7
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-10-10 13:33 PDT by Jer Noble
Modified: 2013-06-07 14:27 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jer Noble 2011-10-10 13:33:41 PDT
From Simon Fraser:

After enabling WebAudio, and playing with some of the demos on http://chromium.googlecode.com/svn/trunk/samples/audio/index.html, the Safari web process started to use huge amounts of memory. In the middle of playing pool <http://chromium.googlecode.com/svn/trunk/samples/audio/o3d-webgl-samples/pool.html> the web content froze, and my machine suddenly had no free memory. Sample and heap attached.

'leaks' shows no leaks though.

Trying again, every web audio demo that I visit causes memory use to go up and up, and that memory is never released.

Comment 1 Jer Noble 2011-10-10 13:34:03 PDT
rdar://problem/10254445
Comment 2 Chris Rogers 2011-10-10 14:24:34 PDT
I suspect this is a garbage collection issue rather than an outright leak (though I could be wrong).  A good test might be the "granular synthesis" demo since it continually generates large numbers of audio sources:
http://chromium.googlecode.com/svn/trunk/samples/audio/granular.html

Once each source (representing a grain) is finished playing then it should be ready to be garbage collected, though large numbers of these sources could build up if collection does not happen frequently.

It might be possible to take a test case like this, then add a "Garbage Collection" button to force garbage collection to see if this helps reduce memory.

If it is a garbage-collection related, then perhaps there's a way to indicate to JSC that these sources need to be collected earlier than they are.
Comment 3 Chris Rogers 2011-10-10 14:28:10 PDT
There is some instrumentation which can be enabled in AudioNode.h to help with node reference debugging:


#define DEBUG_AUDIONODE_REFERENCES 0
Comment 4 Chris Rogers 2011-10-10 18:38:23 PDT
In some quick tests, after enabling DEBUG_AUDIONODE_REFERENCES on a WebKit build, there don't appear to be any leaks in any AudioNode objects, although it might take awhile for some of them to be garbage collected.

It would be good to make a memory-usage comparison of the drum-machine and granular demo (which create lots of sources dynamically) versus a simple one such as the "Visualizer" which has a single static source.
Comment 5 Simon Fraser (smfr) 2011-10-11 18:41:05 PDT
You should probably be calling reportExtraMemoryCost() for various WebAudio-related objects that are exposed to JS. See HTMLCanvasElement::createImageBuffer() for an example.
Comment 6 Chris Rogers 2012-01-05 22:13:08 PST
I believe these are the main culprits:

WebCore/webaudio/AudioBuffer.h
WebCore/platform/audio/AudioArray.h