GNOME Bugzilla – Bug 678504
Trace signal closures from the object instead of the context keep-alive
Last modified: 2012-07-13 03:04:40 UTC
This is something I decided to try after seeing reports of massive memory consumption in gnome-shell, which cannot be explained with normal operation. Basically, it associated signal closures strongly with the object they're connected too, and clears them when the object becomes unreachable from outside. To me, this is a behavior that makes sense, although it could cause subtle bugs.
Created attachment 216875 [details] [review] Trace signal closures from the object instead of the context keep-alive Implement tracing for GObjects and use it so that signal handlers are rooted to the objects they're connected, and not the global object. This means that if the object goes away and the only thing referring to it is the handler function, it is recognized as a cycle by the GC and collected, reducing memory leaks. Other closures, as well as callback trampolines and vfuncs, are still rooted in the usual way.
Review of attachment 216875 [details] [review]: I wonder if we should also do the same for trampolines. Looks fine.
Attachment 216875 [details] pushed as 06aa616 - Trace signal closures from the object instead of the context keep-alive As for trampolines, I thought of it, but where would you root them to? The object on which the method was invoked?
For a vfunc trampoline, it's quite obvious. I guess the object makes some sense, but I don't know if that could cause some issues.
So I think we should back this out until we've landed the fixes for calling JS_BeginRequest inside trace vfuncs. See bug 679832.
Er, nevermind this was fixed by 54d60c278a39ce681b35d172b675a4b2d4449b65. Sorry for the noise.