Bug 69778 – WebProcess was using 7GB RAM after playing with some WebGL/WebAudio demos

• Status: NEW
• Component: Web Audio

[Jer Noble]

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.


[Jer Noble]

rdar://problem/10254445

[Chris Rogers]

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.

[Chris Rogers]

There is some instrumentation which can be enabled in AudioNode.h to help with node reference debugging:


#define DEBUG_AUDIONODE_REFERENCES 0

[Chris Rogers]

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.

[Simon Fraser (smfr)]

You should probably be calling reportExtraMemoryCost() for various WebAudio-related objects that are exposed to JS. See HTMLCanvasElement::createImageBuffer() for an example.

[Chris Rogers]

I believe these are the main culprits:

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