On Mon Feb 9 16:30:06 2026 +0000, Jacek Caban wrote:
we can't be part of gecko's "purple buffer" without replacing the entire refcounting logic to gecko's (which doesn't seem desirable as it will be too slow, nor possible, since we still need the current one for normal jscript without gecko). How does Gecko handle it? If I remember correctly, its JS object don't have a ref-count at all. Could you please describe they are handled in CC? 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10045#note_129228