IBM Research did a multi-VM framework a while back, to host both the CLR (.NET) and the JVM, with an inter-heap cycle collector. I think it was called Parlay, but that name seems to have been reused. Highly non-trivial!
You previously asserted that Mozilla spends more on other non-standard-track work than it would cost to support multiple language runtimes. Where is your evidence? I cited mine with PyXPCOM.
We did the work to support Python alongside JS. It was neither simple in any sense compared to other work (Mozilla does standards-track-only work; this sometimes leads to dead ends, but that's life) nor a good sunk cost.
I'm not here to chinwag with Monday-morning-the-next-decade quarterbacks. First, advert to the complexity you denied up-thread. Then figure out design problems and solutions.
If after a ton of work "on spec", you end up writing good patches, I'll help champion them in. I would like to see a zero-cost cycle collection solution. That's research, not patch-hacking. If you can't acknowledge the problems starting with cycle collection, you're not for real.
EDIT: Aha, "Parley":
http://hirzels.com/martin/papers/vee04-parley.pdf
You previously asserted that Mozilla spends more on other non-standard-track work than it would cost to support multiple language runtimes. Where is your evidence? I cited mine with PyXPCOM.
We did the work to support Python alongside JS. It was neither simple in any sense compared to other work (Mozilla does standards-track-only work; this sometimes leads to dead ends, but that's life) nor a good sunk cost.
I'm not here to chinwag with Monday-morning-the-next-decade quarterbacks. First, advert to the complexity you denied up-thread. Then figure out design problems and solutions.
If after a ton of work "on spec", you end up writing good patches, I'll help champion them in. I would like to see a zero-cost cycle collection solution. That's research, not patch-hacking. If you can't acknowledge the problems starting with cycle collection, you're not for real.