Jason Orendorff wrote: > - Create a library to facilitate interop among multiple > language runtimes in a single process, with distributed garbage > collection, etc. Like SWIG, only much better. Implement it for > Tamarin, XPCOM, CPython, and Java. > > If the last option sounds crazy, it should, but I'll go ahead and > point > out that we've done interop at least 3 times already (LiveConnect, > XPConnect, PyXPCOM), and we're about to do it 2 more times > (ScreamingMonkey needs Tamarin/MSCOM interop; ActionMonkey > needs Tamarin/XPCOM interop). Maybe it's time to do it in a generic > form that other open source projects can use.
Sorry, just catching up on this thread (and trying to keep it concrete). Let's untangle "interop" into 3 categories: memory management, concurrency and calling. And then untangle each of those categories into two concrete sub-headings: semantics and runtime support library. Here's my current picture of "multiple language interop" with some values filled in. Feel free to disagree: - Memory management - semantics: conservative GC + refcount/finalize API - runtime support library: mmGC - Concurrency - semantics: ?? something like request model ?? - runtime support library: ?? JSAPI + moz event queue ?? - Calling - semantics: XPIDL type system (~ subset related to MSCOM) - runtime support library: tamarin JIT + typelibs So ... I'm considering what we're doing here to be about "dynamic-izing the XPCOM/MSCOM/C++ side" not "static-izing the existing dynamic language runtimes". Dynamic language runtimes can already synthesize their own object proxies by inspecting typelibs, and can already walk their own object graphs. Many -- perhaps most? -- do user-level "threading" via a central event queue. So we may need to ask them for these services, but every dynamic language runtime has an API to them. Assuming many dynamic language runtimes *need* long term integration with us. Some dynamic languages may just give up and just write compilers to ABC bytecode. *Cough* JS *cough*. All the better. C++ does need help, but we *have* the libraries we're intending to use. The tamarin JIT and mmGC let us perform very dynamic calling and memory management tasks on C++, quite generally, at a sub-language, machine-code and memory-address level. That's the whole point. IMO there's no need to invent other low-level libraries or additional inter-language semantics here. (To clarify: I'm assuming the "replacement" for XPConnect will drive the Tamarin JIT via reflection on typelibs or XPIDL type representations bundled in ABC, and xptcall will vanish. Correct me if this is not the plan.) -Graydon _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
