Eric (and Sorin), I've got a new tryserver build for you to test: https://treeherder.mozilla.org/#/jobs?repo=try&revision=00193a9f4532ce5bdfd63fc976d1e83430a1d39c https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NPQNI5Q3Rk6s0HyJuX0YCw/runs/0/artifacts/public/build/target.dmg There's a fair chance it will help with these bug's crashes. It doesn't seem to help in my own tests (with ioAccelResourceFinalize() as per the last paragraph in comment #188), but I'm not sure that's relevant. A single IOAccelResource is created every time an IOSurface is initialized, which gets released when the IOSurface is destroyed. This resource is presumably the same "size" as the IOSurface, so it's presumably fairly large, and uses a fairly large amount of video memory or system memory. In Firefox's CoreAnimation code, IOSurfaces are re-used, if possible (they're obtained from and released to a pool). So a long time can pass before they're destroyed. But their [use count is incremented when they're obtained from the pool](https://searchfox.org/mozilla-central/source/gfx/layers/NativeLayerCA.mm#517), and [decremented when they're released back to the pool](https://searchfox.org/mozilla-central/source/gfx/layers/NativeLayerCA.mm#642). My patch causes the OS to "purge" an IOSurface when its use count drops to zero. This doesn't free the IOSurface or its IOAccelResource, but (as best I can tell) does free the resource's backing memory (video memory or system memory). My hope is that this will reduce the pressure on your 5K iMac's video "resources" (video memory or system memory) enough to at least reduce the frequency of this bug's crashes. Please test with this tryserver build and let us know your results. You'll likely have to test with it for at least a week to be sure.
Bug 1576767 Comment 190 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Eric (and Sorin), I've got a new tryserver build for you to test: https://treeherder.mozilla.org/#/jobs?repo=try&revision=00193a9f4532ce5bdfd63fc976d1e83430a1d39c https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NPQNI5Q3Rk6s0HyJuX0YCw/runs/0/artifacts/public/build/target.dmg There's a fair chance it will help with these bug's crashes. It doesn't seem to help in my own tests (with ioAccelResourceFinalize() as per the last paragraph in comment #188), but I'm not sure that's relevant. A single IOAccelResource is created every time an IOSurface is initialized, which gets released when the IOSurface is destroyed. This resource is presumably the same "size" as the IOSurface, so it's presumably fairly large, and uses a fairly large amount of video memory or system memory. In Firefox's CoreAnimation code, IOSurfaces are re-used, if possible (they're obtained from and released to a pool). So a long time can pass before they're destroyed. But their [use count is incremented when they're obtained from the pool](https://searchfox.org/mozilla-central/source/gfx/layers/NativeLayerCA.mm#517), and [decremented when they're released back to the pool](https://searchfox.org/mozilla-central/source/gfx/layers/NativeLayerCA.mm#642). My patch causes the OS to "purge" an IOSurface when its use count drops to zero. This doesn't free the IOSurface or its IOAccelResource, but (as best I can tell) does free the resource's backing memory (video memory or system memory). My hope is that this will reduce the pressure on your 5K iMac's video "resources" (video memory and system memory) enough to at least reduce the frequency of this bug's crashes. Please test with this tryserver build and let us know your results. You'll likely have to test with it for at least a week to be sure.