DeleteSoon and Memory Leaks

[Scott Haseley]

Hi scheduler-dev,

I've recently been looking into memory leaks in Blink caused by DeleteSoon/ReleaseSoon, and I wanted to share and solicit feedback.

The problem is these APIs post a task to delete/release an object, but the object will leak if the deleter task doesn't run (it doesn't automatically get deleted on task destruction). In general, it's only okay to leak these objects if the process is shutting down -- but we don't enforce that. This is problematic in Blink since the renderer process can long outlive worker- and frame-associated task queues.

This doc goes into details about the problem and potential solutions. I think there's a pragmatic way to fix the bulk of the issue in Blink by specializing the deleter task behavior for Blink task runners, and I'm proposing to start there since we know this is an issue in Blink. I'm less familiar with scheduling outside of Blink, and it's not clear to me how widespread this problem is (usage is widespread) or what guarantees/checks we want to provide in general. But we probably want to consider finding a long-term solution because it's dangerous/leaky when used with certain task runners.

Comments on the doc would be appreciated if folks have opinions, as well as thoughts about how much of a problem this might be outside of Blink and what we might want to do with these APIs.

Thanks,

Scott