Right now our Gecko Media Plugins implementation uses up to three Shmem objects to back a single frame. The problem with this is that it leads to us hitting file descriptor limits (~10k) and crashing the parent process when we queue to many frames for processing. There are some other downsides as well, including non-trivial IPC/allocation overhead. One solution is to use a single Shmem object for multiple frames. This bug is about pursuing such a solution.

WIP patch to recycle YUV buffer and encoded-data buffers back and forth across the interface. Has a limit on the number that can accumulate on one side; I could (if it matters) send them in IPC messages to the other side if there's an inbalance (and then free there if it has "enough" too). Right now if there are 10 in a pool on one side; it will delete to keep the limit at 10. Note that one-way calls will be totally imbalanced and all buffers would get deleted and not recycled, so we may want to include the return messages (there's some earlier work towards a version of that in this patch which should be cleaned up/reworked to do that). IN a ~15 minute call, I saw ~280K recycles of buffers, and ~1500 allocations (most of the time it was sitting at ~500), and then I ran out of something and failed a shmem alloc. Memory used in the pools was a couple of meg and appeared stable.

Comment on attachment 8448022 [details] [diff] [review] wip_shmem.patch Review of attachment 8448022 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/gmp/moz.build @@ +47,5 @@ > 'GMPPlatform.cpp', > 'GMPProcessChild.cpp', > 'GMPProcessParent.cpp', > 'GMPService.cpp', > + 'GMPSharedMemManager.cpp', This file doesn't exist.

Forgot hg add for GMPSharedMemManager.cpp

WIP and attempts to proxy everything to the parent. Builds cleanly, but when we call SendNeedShmem(size, &mem), it runs and seems to return an Shmem in the parent, but the child fails with Error deserializing 'Shmem'. Very close I believe.

The shmem pools patch worked solidly for me on OSX running for 20mins or so. The plugin process still leaks some memory though. Perhaps I will do some more frame counting.

Cleaned up for review - and the plugin failure cutout has been tested and works (killing the plugin container while in use)

Comment on attachment 8449120 [details] [diff] [review] Proxy all GMP Shmem create/delete to parent and reduce allocation traffic Review of attachment 8449120 [details] [diff] [review]: ----------------------------------------------------------------- Ben is busy so I'll do the review instead

Comment on attachment 8449120 [details] [diff] [review] Proxy all GMP Shmem create/delete to parent and reduce allocation traffic Review of attachment 8449120 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. The whole thing is based on the idea that using intr protocols solves the problem of synchronously allocating a shmem on the parent and returning to the child side. I don't know how intr actually works so I am assuming it does work :) (and I am genuinely interested in it working because some gfx ipc code will most likely need to use the same trick at some point).

Something in this push was causing leaks. Backed out. https://hg.mozilla.org/integration/mozilla-inbound/rev/70f3b01cb736 https://tbpl.mozilla.org/php/getParsedLog.php?id=43566548&tree=Mozilla-Inbound

Landed with fix: https://hg.mozilla.org/integration/mozilla-inbound/rev/c928106052fe https://hg.mozilla.org/integration/mozilla-inbound/rev/b1ba940ea14b

https://hg.mozilla.org/mozilla-central/rev/c928106052fe https://hg.mozilla.org/mozilla-central/rev/b1ba940ea14b