map.setFilter huge memory leak in safari

[stackTom]

mapbox-gl-js version:
0.35.0

Steps to Trigger Behavior

1. use map.setFilter on a relatively large vector tile source from mbtiles

Expected Behavior

memory use doesn't sky-rocket

Actual Behavior

memory use goes up to 2.00 gb+ and keeps on climbing sometimes. Removing the source doesn't reduce the memory used. This technique works fine on chrome.

Example:
http://insarmaps.rsmas.miami.edu/?startDataset=CSK_HIMAGE_091_0000_20130914-20170116_0000_00000

I am loading vector tiles from a vector tile server. I am then requesting points to filter from the server. The server returns a couple of thousand of point ids, and I use these as a filter on the vector tile layer in order to not display the points with these ids:
var filter = ["in", "p"].concat(pointIDs); map.setFilter(layerID, filter);

On chrome, memory use doesn't rise by much, but in safari for mac os sierra v 10.12.4, memory use goes so high as to cause my 8gb machine to begin to use swap space. If I press the reset button and remove the vector tile source from the map, memory use stops increasing and remains the same until I close the app.

[mourner]

Thanks for the report! Could you please set up an isolated JSFiddle test case that reproduces the issue? That would make triaging it much easier.

[stackTom]

Here is the fiddle: http://jsfiddle.net/n9xowfru/7/
Safari seemed to stabilize at around 2.2 gig (chrome at around 280 meg). After I opened a new tab in chrome to respond here on github, safari went crazy, and memory shot up to 16.6 gig before I force quit it (in the below picture, I was able to grab it at 14 gig, but it kept rising after I took the picture). Notice that chrome is at 193 meg, jumping from around 193 to 400+ or so.
Hope this can be fixed, as this is vital to my application.

[anandthakker]

Here's a slightly modified version of the fiddle where the filter is set only after clicking on the map - might make profiling a little easier: http://jsfiddle.net/xfkysxmw/5/

[mourner]

This was likely fixed by #9003, in addition to being fixed on the WebKit side in https://bugs.webkit.org/show_bug.cgi?id=203990