1243091 - Implement automatic leak detection

Status: NEW

(DevTools :: Memory, defect, P2)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

This paper describes a really cool and effective way to automatically discover leaky paths over N snapshots: http://www.cs.utexas.edu/ftp/techreports/tr06-07.pdf

We can add a method to the webidl HeapSnapshot interface to expose the types-from graph for the snapshot and then compute the leaky slices in JS, or do the whole thing in C++ by exposing a method HeapSnapshot.detectLeaks([s1, s2, ... sn]) that returns the leaky slices directly. I'm leaning towards doing the whole thing in C++, because this could probably benefit from predictable performance and type checking.

Comment 1

[David Bruant]

(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #0)
> This paper describes a really cool and effective way to automatically
> discover leaky paths over N snapshots:
> http://www.cs.utexas.edu/ftp/techreports/tr06-07.pdf

This paper seems to heavily rely on types to do its work. What would you be using in JS? Shapes?

I quite enjoyed the "Correlating to Data Structures and Allocation Sites" section but it left me wondering whether tracking per-allocation-site growth wouldn't just be more useful. Maybe it's expensive at the beginning to track all allocation sites, but it's also easy to discard the sites where the memory has been freed to keep only the few allocation sites that seem to generate memory that stays around.

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to David Bruant from comment #1)
> This paper seems to heavily rely on types to do its work. What would you be
> using in JS? Shapes?

We have a set of "counters" that can be nested to categorize a node in an open ended manner. These counters can categorize by [[class]] name, allocation site, etc.

> I quite enjoyed the "Correlating to Data Structures and Allocation Sites"
> section but it left me wondering whether tracking per-allocation-site growth
> wouldn't just be more useful.

This is already possible by doing the following:

* Start recording allocation stacks
* Take a snapshot
* Play with your webapp
* Take a second snapshot
* Diff the first and second snapshot
* Set "group by" to "allocation stack"

Comment 3

[David Bruant]

(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #2)
> (In reply to David Bruant from comment #1)
> > I quite enjoyed the "Correlating to Data Structures and Allocation Sites"
> > section but it left me wondering whether tracking per-allocation-site growth
> > wouldn't just be more useful.
> 
> This is already possible by doing the following:
> 
> * Start recording allocation stacks
> * Take a snapshot
> * Play with your webapp
> * Take a second snapshot
> * Diff the first and second snapshot
> * Set "group by" to "allocation stack"

oh sorry, no, I meant per-allocation-site growth wouldn't just be more useful as a way to categorize objects instead of using types as they do in the paper.


(In reply to Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] from comment #2)
> (In reply to David Bruant from comment #1)
> > This paper seems to heavily rely on types to do its work. What would you be
> > using in JS? Shapes?
> 
> We have a set of "counters" that can be nested to categorize a node in an
> open ended manner. These counters can categorize by [[class]] name,
> allocation site, etc.

and which category were you planning on using? (that's where I suggested allocation site might be a good candidate, but maybe you had something else in mind)