1079224 - Compartments are leaked when running membench with compacting GC

Status: RESOLVED WORKSFORME

(Core :: JavaScript: GC, defect)

Description

[Jon Coppeard (:jonco)]

As reported by njn in bug 650161.  I'm splitting the investigation off into a new bug.

> I just tried MemBench (http://www.gregor-wagner.com/tmp/mem50) again with mozilla-
> inbound and the 27-fixup-after-jsobject-changes patch. I still get leaked
> compartments after closing all the test windows (including MemBench itself):

> ├───39.83 MB (09.76%) -- window-objects
> │   ├──30.85 MB (07.56%) -- top(none)/detached/window([system])
> │   │  ├──16.18 MB (03.96%) -- (12 tiny)
> │   │  │  ├───2.48 MB (00.61%) ++ js-compartment(http://www.msn.com/en-au/)
> │   │  │  ├───2.30 MB (00.56%) ++ js-compartment(http://www.spiegel.de/)
> │   │  │  ├───2.13 MB (00.52%) ++ js-compartment(http://www.microsoft.com/en-au/default.aspx)
> │   │  │  ├───1.89 MB (00.46%) ++ js-compartment(http://www.kleinezeitung.at/)
> │   │  │  ├───1.85 MB (00.45%) ++ js-compartment(http://www.britishairways.com/travel/home/public/en_gb)
> │   │  │  ├───1.70 MB (00.42%) ++ dom
> │   │  │  ├───0.78 MB (00.19%) ++ js-compartment(http://www.bing.com/)
> │   │  │  ├───0.71 MB (00.17%) ++ js-compartment(https://www.youtube.com/watch?v=a1Y73sPHKxw, about:blank)
> │   │  │  ├───0.70 MB (00.17%) ++ js-compartment(http://www.msn.com/en-au/, about:blank)
> │   │  │  ├───0.68 MB (00.17%) ++ js-compartment(http://techcrunch.com/wp-content/themes/vip/techcrunch-2013/_uac/adpage.html, about:blank)
> │   │  │  ├───0.67 MB (00.16%) ++ js-compartment(http://www.bild.de/, about:blank)
> │   │  │  └───0.30 MB (00.07%) ++ js-compartment(http://platform.twitter.com/widgets/hub.1c5a573e465d84666458a45e49b0a735.html)
> │   │  ├───5.41 MB (01.32%) ++ js-compartment(https://www.youtube.com/watch?v=a1Y73sPHKxw)
> │   │  ├───4.72 MB (01.16%) ++ js-compartment(http://www.bild.de/)
> │   │  └───4.54 MB (01.11%) ++ js-compartment(http://techcrunch.com/2011/07/07/facebook-now-lets-app-developers-see-their-spam-scores/)

Comment 1

[Jon Coppeard (:jonco)]

I spent a while yesterday trying to track this this problem down.

I was able to reproduce it only rarely.  It happened the first two times I tried and then almost never again in my testing.

Some possible theories as to what is going wrong:

1) There's a pointer to a moved object that is not being updated properly and when this is later marked through it causes otherwise unreachable data to be marked.

2) Compacting makes the GCs take longer (particularly relevant for the the membench example) and this is interfering with the timing we use to trigger GCs and CCs, with the result that the sequence necessary is not being run.

I wasn't able to reproduce this when I had any logging enabled to confirm or deny (2).

For (1) I'm going to make a patch that in debug builds relocated arenas remain unmapped until the start of the next GC which should catch this kind of problem.

Comment 2

[Jon Coppeard (:jonco)]

No longer reproduces since the patch in bug 650161 comment 202 landed.