Benjamin Smedberg wrote: > Brendan Eich wrote: > >> Or an unstable API. It's what everyone else does. Stability arises >> through a "conversation" between producers and consumers, and over time >> increases, until there's a "big shift". This came up in face-to-face >> meetings, and we should hash it out. >> >> New thread in .embedding, cross-posted here with followup-to: set? > > Sure. The important point was not the stability or instability of the > embedding API, but that it is entirely decoupled from "XPCOMGC".
Indeed, and I'm with you on that point. It's non-trivial with exact GC, since you end up requiring fat handles (roots or scannable thread-local helpers such as SpiderMonkey's JSTempValueRooters), and these can't be hidden even with C++ auto-storage-class automation. Think of the JNI with its global and local (per-activation) roots, and the need to manage the latter when you create thousands of newborns and connect each as you go to the live object graph. We don't want a JNI-like embedding API just to future-proof for exact GC. We might evolve MMgc toward a more exact mode of operation, but there's little motivation for that now. So we are probably committing to at least conservative stack scanning in our GC, by using simple embedding APIs. I'm assuming the embedding APIs will involve pointers to GC-allocated things. Copying strings in and out can get expensive depending on the embedding. But this is fodder for the new thread. /be _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
