Geolocation is now part of the cycle collector. It really wasn’t that hard, but there are some parts that were confusing. So, here are some hints…
If you need to add something to the mozilla cycle collector, the first thing is to look at every class that you want to have participate in collection. What I did was look at every member variable in each class and draw a simply diagram:
This diagram doesn’t have to be pretty or follow every rule of the Unified Modeling Language. It is just suppose to help you understand what is going on. (This is something you might even want to attach to the bug that you are working on because it will help your reviewers.) Remember to look at each and every member variable. For each member, create a new class block, and repeat. There are some classes that can be safely ignored — nsITimers, and nsIURIs for example, but it is probably best to just include everything if in doubt. From this little exercise, you can see that there is a cycle between the nsGeolocation, its callbacks, and the dom window, and between the nsGeolocation and the nsGeolocationRequests. There is also cycle between the nsGelocationService and the nsGeolocation.
For each cycle you need to look at the ownership model. If the link is a weak reference, you can ignore that link. From this diagram and the reduction of any weak references from the graph, you should be able to have a list of classes which need to participate. This is a pretty simple system. The complete analysis took an hour or so. However, I got some help from peterv and dbaron which did help me better understand what I was suppose to be looking for.
The next step is to actually modify your classes so that they participate. Read the Interfacing with the XPCOM cycle collector document. For most things, this document will tell you everything you wanted to know about using the mozilla cycle collector. However, for my system, I was using nsTArrays of nsRefPtrs and there wasn’t a pretty macro that hide everything. For this case, so I had to actually write some non-marcro-real-code for this.
It turned out, it wasn’t that painful and the patch landed on mc last night.
4 Comments
Hello Doug,
Do you think that this process can be automated by a simple script wrapping something like lxr or etags? Are there a lot of judgment calls required to generate the dependency graph?
yeah, totally possible. i am not doing anything smart when i look at the classes. I wouldn’t be surprised if we already had tools to look for cycles.
Honestly, I’m a bit surprised by what I read here. I thought the mozilla cycle collector automatically detected this kind of cases. I’ll try to read about how it works exactly, because it seems quite more lighweight that I thought originally, which makes it more interesting for me ! I just don’t like the idea of supporting the cost of doing dynamically what can reasonnably be statically checked at compile time.
some old development links: https://wiki.mozilla.org/CycleCollector