Queue GC when a GObject reference is toggled down
From IRC:
ptomato[m] meaning during a GC, the collector asks each object which other objects that it wants to hold on to
so if there's an entire section of the heap graph that's not connected to anything else, and not reachable from the root set, then it can be trashed all at once
GObjects don't work like that, there's only a reference count but no notion of who owns the reference
so, a JS object that's proxying a GObject is unconditionally held alive as long as the GObject has >1 references
this is related to the "parentless" GObjects that andyholmes has been seeing in the heap graphs
this must be why immediately successive GCs keep reducing the memory - each time, a JS object proxying a GObject with only one reference is trashed
(the GObject's one reference is owned by the JS object itself)
that unrefs other GObjects, and brings them down to only 1 reference
which makes more JS objects eligible for trashing
This is likely the cause of the not immediate memory releases that are being observated in gnome-shell#64 (closed).
Edited by Georges Basile Stavracas Neto