On Mon Feb 9 16:30:06 2026 +0000, Gabriel Ivăncescu wrote:
From what I have seen, and I could be wrong on the details, it's that gecko has two separate collectors. The cycle collector (CC), which is what I use here because it deals with refcounted objects, and the garbage collector (GC) used by its JS engine. As you said, JS objects don't have refcounts, they rely on a generational tracing GC that manages JS objects by tracing roots (marking reachable objects, and collecting unreachable ones). Root is like the stack or global scope and so on. The top comments in nsCycleCollector.cpp also mention how there's some downsides to their JS<->C++ object interactions this way, so it's probably not ideal for us. Furthermore, I don't think it's even feasible in the first place because our JS objects can become "C++ Objects" when exposed via COM (and even though it seems unlikely, it's possible in theory and we have tests for it already, I don't think we should aim for a wrong upstream approach). And so they need a proper refcount, which gecko's JS objects don't have. Note that the fake refcount I mentioned only applies to what we tell gecko, it's not user visible nor something exposed to the COM world. There's also the fact we rely on refcounting in our jscript engine, and we definitely need it for standalone jscript (without mshtml, or even pre IE9). I haven't got too deep into the details of how gecko's GC works (not the CC), nor its API. I don't even know if it's available to us since it's not XPCOM (and it's internal only). I don't think it's something we can, or should, use. But let me know if you have some ideas to pursue. I did not mean to suggest removing reference counting from JS objects. My point was that Gecko faces the same problem: objects without an associated `nsCycleCollectingAutoRefCnt` can still be part of a cycle. I was wondering what the intended solution is in that case, that is, how the cycle collector authors expected this to be handled. From your description, it sounds like GC is supposed to be used for that instead of the CC? I do not think Gecko's GC is directly useful for us, but in theory, whatever strategy they use there could be replicated in our jscript GC.
In your implementation, what you are doing in `describe_node` is not really how `nsCycleCollectingAutoRefCnt` is meant to be used. This might happen to work for full CC runs, but using a temporary stack-based ref is still a hack, right? And to make that hack work, you end up needing more hacks in places like QI, which now depends on CC state? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10045#note_129246